<?xml version="1.0" encoding="windows-1252"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc strict="yes" ?> version='1.0' encoding='utf-8'?>
<rfc ipr="trust200902" xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-mmusic-t140-usage-data-channel-14" obsoletes="" updates="8373" indexInclude="true" ipr="trust200902" number="8865" prepTime="2021-01-18T23:00:08" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="8373" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel-14" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8865" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="T.140 Data Channel">
       T.140 Real-time Channel">T.140 Real-Time Text Conversation over WebRTC Data Channels
    </title> Channels</title>
    <seriesInfo name="RFC" value="8865" stream="IETF"/>
    <author initials="C.H." initials="C." surname="Holmberg" fullname="Christer Holmberg">
      <organization>Ericsson</organization>
      <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.H." surname="Hellstrom" initials="G." surname="Hellström" fullname="Gunnar Hellstrom">
      <organization>Gunnar Hellstrom Hellström">
      <organization showOnFrontPage="true">Gunnar Hellström Accessible Communication</organization>
      <address>
        <postal>
          <street>Esplanaden 30</street>
          <code>136 70</code>
          <city>Vendelso</city>
          <city>Vendelsö</city>
          <country>Sweden</country>
        </postal>
        <email>gunnar.hellstrom@ghaccess.se</email>
      </address>
    </author>
    <date year="2020"/>
    <area>Transport</area>
    <workgroup>MMUSIC Working Group</workgroup> month="01" year="2021"/>
    <keyword>SDP</keyword>
    <keyword>ITU-T</keyword>
    <keyword>T.140</keyword>
    <keyword>Data Channel</keyword>
    <keyword>WebRTC</keyword>
    <keyword>real-time text</keyword>
    <abstract>
      <t>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
        This document specifies how a WebRTC Web Real-Time Communication (WebRTC) data channel can be used as a
        transport mechanism for Real-time real-time text using the ITU-T Protocol for multimedia
        application text conversation (Recommendation ITU-T T.140), T.140) and
        how the SDP Session Description Protocol (SDP) offer/answer mechanism can be 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.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8865" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="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 derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions">Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-webrtc-data-channel-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" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-considerations">SDP Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-use-of-the-dcmap-attribute">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 derivedContent="" format="title" sectionFormat="of" target="name-use-of-the-dcsa-attribute">Use of the 'dcsa' Attribute</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-maximum-character-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 derivedContent="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 derivedContent="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 derivedContent="" format="title" sectionFormat="of" target="name-examples">Examples</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-t140-considerations">T.140 Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-session-layer-functions">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 derivedContent="" format="title" sectionFormat="of" target="name-data-encoding-and-sending">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 derivedContent="" format="title" sectionFormat="of" target="name-data-buffering">Data Buffering</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 derivedContent="" format="title" sectionFormat="of" target="name-loss-of-t140blocks">Loss 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 derivedContent="" format="title" sectionFormat="of" target="name-multi-party-considerations">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" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-gateway-considerations">Gateway Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="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" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="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" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-sdp-fmtp-attribute">SDP '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 derivedContent="" format="title" sectionFormat="of" target="name-sdp-language-attributes">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 derivedContent="" format="title" sectionFormat="of" target="name-sdp-media-direction-attribu">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" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-normative-references">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 derivedContent="" format="title" sectionFormat="of" target="name-informative-references">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="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction" toc="default">
      <t> toc="include" numbered="true" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
        The ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140)
        <xref target="T140"/> target="T140" format="default" sectionFormat="of" derivedContent="T140"/> defines a protocol for text conversation, also known as
        real-time text. The transport used for IP networks is the "RTP Payload
        for Text Conversation" mechanism <xref target="RFC4103"/> mechanism, target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>, based on the Real-time Transport Protocol (RTP) <xref target="RFC3550"/>.
      </t>
      <t> target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>.
      </t>
      <t indent="0" pn="section-1-2">
        This document specifies how a WebRTC Web Real-Time Communication (WebRTC) data channel <xref target="I-D.ietf-rtcweb-data-channel"/> target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/>
        can be used as a transport mechanism for T.140, T.140 and how the SDP Session
        Description Protocol (SDP) offer/answer mechanism
        for data channels <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/> can be used to negotiate such a data channel.
      </t>
      <t>
      <t indent="0" pn="section-1-3">
        In this document, a T.140 data channel refers to a WebRTC data channel for which
        the instantiated sub-protocol subprotocol is "t140", "t140" and where the channel is negotiated
        using the SDP-based external negotiation method SDP offer/answer mechanism <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.
      </t>
      <t> target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>.
      </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 channel, channel
        instead of using RTP based RTP-based transport <xref target="RFC4103"/>, target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>
        is motivated by use-case 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 conference", conference";
        see Section 3.2 of <xref target="I-D.ietf-rtcweb-data-channel"/>.
      </t>
      <t> target="RFC8831" sectionFormat="of" section="3.2" format="default" 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
        conversation protocol according to <xref target="T140"/>.
      </t>
      <t> target="T140" format="default" sectionFormat="of" derivedContent="T140"/>.
      </t>
      <t indent="0" pn="section-1-6">
        Real-time text is intended to be entered by human users from via a keyboard,
        handwriting recognition, voice recognition recognition, or any other input method.
        The rate of character entry is usually at a level of a few characters
        per second or less.
      </t>
      <t>
        <xref target="sec.webrtc.cons"/>
      <t indent="0" pn="section-1-7">
        <xref target="sec.webrtc.cons" format="default" sectionFormat="of" derivedContent="Section 3"/> defines the generic data channel properties for
        a T.140 data channel, and <xref target="sec.sdp"/> target="sec.sdp" format="default" sectionFormat="of" derivedContent="Section 4"/> defines how they are conveyed
        in an SDP dcmap 'dcmap' attribute. While this document defines how to establish negotiate a
        T.140 data channel using the SDP-based external negotiation method SDP offer/answer mechanism
        <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>, target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>, the generic T.140 and gateway
        considerations defined in <xref target="sec.webrtc.cons"/>, <xref target="sec.t140"/>
        and <xref target="sec.gw"/> Sections <xref target="sec.webrtc.cons" format="counter" sectionFormat="of" derivedContent="3"/>, <xref target="sec.t140" format="counter" sectionFormat="of" derivedContent="5"/>,
        and <xref target="sec.gw" format="counter" sectionFormat="of" derivedContent="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
        <xref target="I-D.ietf-rtcweb-data-protocol"/>). Section 5 of
        <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>). <xref target="RFC8864" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8864#section-5" derivedContent="RFC8864"/>
 defines the mapping between the
        SDP dcmap 'dcmap' attribute parameters and the protocol parameters used in
        <xref target="I-D.ietf-rtcweb-data-protocol"/>.
      </t>
      <t> target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>.
      </t>
      <t indent="0" pn="section-1-8">
        This document updates <xref target="RFC8373"/>, target="RFC8373" format="default" sectionFormat="of" derivedContent="RFC8373"/> by defining how the SDP
        hlang-send
        'hlang-send' and hlang-recv 'hlang-recv' attributes are used for the "application/webrtc-datachannel"
        media type.
      </t>
    </section>
    <section title="Conventions">
      <t>
        The numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions">Conventions</name>
      <t indent="0" pn="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP 14
       <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.
      </t> here.</t>
    </section>
    <section anchor="sec.webrtc.cons" title="WebRTC numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-webrtc-data-channel-conside">WebRTC Data Channel Considerations">
      <t> Considerations</name>
      <t indent="0" pn="section-3-1">
        The following WebRTC data channel property values <xref target="I-D.ietf-rtcweb-data-channel"/> target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/>
        apply to a T.140 data channel:
      </t>
      <texttable title="">
        <ttcol align='left' width='30%'/>
        <ttcol align='left'/>

        <c>Subprotocol Identifier</c>
        <c>t140</c>

        <c>Transmission reliability</c>
        <c>reliable</c>

        <c>Transmission order</c>
        <c>in-order</c>

        <c>Label</c>
        <c>See <xref target="sec.sdp.dcmap"/> and <xref target="sec.gw"/></c>
      </texttable>
      <t>
      <table align="center" pn="table-1">
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">Subprotocol Identifier</td>
            <td align="left" colspan="1" rowspan="1">t140</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Transmission reliability</td>
            <td align="left" colspan="1" rowspan="1">reliable</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Transmission order</td>
            <td align="left" colspan="1" rowspan="1">in-order</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Label</td>
            <td align="left" colspan="1" rowspan="1">See <xref target="sec.sdp.dcmap" 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 real-time text without
        duplication and in original order. Therefore, T.140 does not specify reliable and ordered
        transmission of T.140 data on the application layer. Instead, when RTP based RTP-based transport is used,
        the RTP sequence number is used to detect packet loss and out-of-order packets, and a redundancy
        mechanism is used to achieve reliable delivery of T.140 data. By using
        the WebRTC data channel channel's reliable and in-order transmission features <xref target="I-D.ietf-rtcweb-data-channel"/> 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
        data loss and out-of-order delivery at the application level. The latency characteristics of the
        T.140 data channel is are also regarded to be as sufficient to meet the application requirements of T.140.
        </t>
      </aside>
    </section>
    <section anchor="sec.sdp" title="SDP Considerations">
      <t> numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-sdp-considerations">SDP Considerations</name>
      <t indent="0" pn="section-4-1">
        The generic SDP considerations, including the SDP Offer/Answer offer/answer procedures <xref target="RFC3264"/>, target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>, for
        negotiating a WebRTC data channel are defined in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>. target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>.
        This section, and its subsections, define the SDP considerations that are specific to a T.140 data channel,
        identified by an SDP 'dcmap' the 'subprotocol' attribute <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> parameter, with a "t140"
        attribute
        parameter value. value, in the 'dcmap' attribute.
      </t>
      <section anchor="sec.sdp.dcmap" title="Use numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-use-of-the-dcmap-attribute">Use of dcmap Attribute">
        <t> the 'dcmap' Attribute</name>
        <t indent="0" pn="section-4.1-1">
           An offerer and answerer MUST, <bcp14>MUST</bcp14>, in each offer and answer, include an SDP 'dcmap'
           attribute <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/> in the SDP media
           description (m= section) ("m=" section) <xref target="I-D.ietf-mmusic-rfc4566bis"/> target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> describing
           the SCTP Stream Control Transmission Protocol (SCTP) association
           <xref target="RFC4960"/> target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960"/> used to realize the T.140
           data channel.
        </t>
        <t>
        <t indent="0" pn="section-4.1-2">
          The offerer and answerer MUST <bcp14>MUST</bcp14> include the subprotocol 'subprotocol' attribute parameter,
          with a "t140" parameter value, in the 'dcmap' attribute value. attribute.
        </t>
        <t>
        <t indent="0" pn="section-4.1-3">
          The offerer and answerer MAY <bcp14>MAY</bcp14> include the priority 'priority' attribute parameter
          and the label 'label' attribute parameter in the 'dcmap' attribute value, as
          specified in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>.
        </t>
        <t> target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>.
        </t>
        <aside pn="section-4.1-4">
          <t indent="0" pn="section-4.1-4.1">
          NOTE: As specified in <xref target="I-D.ietf-rtcweb-data-channel"/>, target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/>,
          when a data channel is negotiated using the mechanism defined in <xref target="I-D.ietf-rtcweb-data-protocol"/>, target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC8832"/>,
          the label 'label' attribute parameter value has to be the same in both directions. That rule also
          applies to data channels negotiated using the mechanism defined in this document.
          </t>
        <t>
        </aside>
        <t indent="0" pn="section-4.1-5">
          The offerer and answerer MUST NOT <bcp14>MUST NOT</bcp14> include the max-retr 'max-retr' or the max-time 'max-time'
          attribute parameters parameter in the 'dcmap' attribute. If either of those
          attribute parameters is received in an offer, the answerer
          MUST
          <bcp14>MUST</bcp14> reject the offer. If either of those attribute parameters is received
          in an answer answer, the offerer MUST NOT <bcp14>MUST NOT</bcp14> accept the answer. Instead, the answerer
          MUST
          <bcp14>MUST</bcp14> take appropriate actions, e.g., by sending a new offer without a
          T.140 data channel, channel or by terminating the session.
        </t>
        <t>
        <t indent="0" pn="section-4.1-6">
          If the ordered 'ordered' attribute parameter is included in the 'dcmap' attribute, it MUST <bcp14>MUST</bcp14>
          be assigned the value 'true'.
        </t>
        <t>
        <t indent="0" pn="section-4.1-7">
          Below is an example of the 'dcmap' attribute for a T.140
          data channel with stream id=3 and without any label:
        </t>
        <t>
        <t indent="0" pn="section-4.1-8">
          a=dcmap:3 subprotocol="t140"
        </t>
      </section>
      <section anchor="sec.sdp.dcsa" title="Use numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-use-of-the-dcsa-attribute">Use of dcsa Attribute">
        <t> the 'dcsa' Attribute</name>
        <t indent="0" pn="section-4.2-1">
           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-sdpneg"/> target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>
           in the m= "m=" section describing the SCTP association used
           to realize the T.140 data channel.
        </t>
        <t>
        <t indent="0" pn="section-4.2-2">
          If an offerer or answerer receives a 'dcsa' attribute that contains an
          SDP attribute which whose usage has not been defined for a T.140 data channel,
          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"/>. target="RFC8864" sectionFormat="of" section="6.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8864#section-6.7" derivedContent="RFC8864"/>.
        </t>
        <section anchor="sec.sdp.dcsa.trans" title="Maximum numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-maximum-character-transmiss">Maximum Character Transmission Rate">
          <t> Rate</name>
          <t indent="0" pn="section-4.2.1-1">
            A 'dcsa' attribute can contain the SDP 'fmtp' attribute attribute, which is used to indicate
            a maximum character transmission rate <xref target="RFC4103"/>. target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>. The 'cps'
            attribute parameter is used to indicate the maximum character transmission rate
            that the endpoint that includes the attribute is able to receive, and the value
            is used as a mean value in characters per second over any 10-second interval.
          </t>
          <t>
          <t indent="0" pn="section-4.2.1-2">
            If the 'fmtp' attribute is included, the 'format' attribute
            parameter MUST value <bcp14>MUST</bcp14> be set to "t140". 't140'.
          </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
            30 applies <xref target="RFC4103"/>.
          </t>
          <t> target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>.
          </t>
          <t indent="0" pn="section-4.2.1-4">
            The offerer and answerer MAY <bcp14>MAY</bcp14> modify the 'cps' attribute parameter value in subsequent
            offers and answers.
          </t>
          <t>
          <t indent="0" pn="section-4.2.1-5">
            This document does not define any other usage of the 'fmtp' attribute for a T.140 channel.
            If an offerer or answerer receives a 'dcsa' attribute that contains an 'fmtp' attribute that
            is not set according to the procedure above, the offerer or answerer MUST <bcp14>MUST</bcp14> ignore the 'dcsa'
            attribute.
          </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.140 data channel
            endpoint is acting as a gateway (<xref target="sec.gw"/>) target="sec.gw" format="default" sectionFormat="of" derivedContent="Section 6"/>) and is interworking with
            a T.140 transport mechanism that have has restrictions on how many characters can be sent
            per second.
            </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
            sending endpoint does not support the 'cps' attribute parameter,
            it SHOULD <bcp14>SHOULD</bcp14> either
            indicate (1) indicate to the sending endpoint that it is not willing to receive more text, using
            the direction attributes (<xref target="sec.sdp.dcsa.dir"/>), target="sec.sdp.dcsa.dir" format="default" sectionFormat="of" derivedContent="Section 4.2.3"/>) or use (2) use a flow control flow-control
            mechanism to reduce the rate. However, in certain applications, e.g. e.g., emergency services,
            it is important to regain human interaction as soon as possible, and it might
            therefore be more appropriate to simply discard the received overflow, insert a
            mark for loss <xref target="T140ad1"/>, target="T140ad1" format="default" sectionFormat="of" derivedContent="T140ad1"/>, and continue to process the received text as
            soon as possible.
          </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 API for WebRTC data channels
            does not support flow control. Should such support be available at some point, a receiving endpoint
            might use it in order to slow down the rate of text received from the sending endpoint.
            </t>
          </aside>
        </section>
        <section anchor="sec.sdp.dcsa.lan" title="Real-time numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-real-time-text-conversation">Real-Time Text Conversation Languages">
         <t> Languages</name>
          <t indent="0" pn="section-4.2.2-1">
            'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes
            <xref target="RFC8373"/> target="RFC8373" format="default" sectionFormat="of" derivedContent="RFC8373"/> to negotiate the language to be used for the real-time
            text conversation.
          </t>
        <t>
          <t indent="0" pn="section-4.2.2-2">
            For a T.140 data channel, the modality is "written" <xref target="RFC8373"/>. target="RFC8373" format="default" sectionFormat="of" derivedContent="RFC8373"/>.
          </t>
        </section>
        <section anchor="sec.sdp.dcsa.dir" title="Real-time numbered="true" toc="include" removeInRFC="false" pn="section-4.2.3">
          <name slugifiedName="name-real-time-text-direction">Real-Time Text Direction">
          <t> Direction</name>
          <t indent="0" pn="section-4.2.3-1">
            'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendrecv' 'sendrecv', and
            'inactive' attributes <xref target="I-D.ietf-mmusic-rfc4566bis"/> target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> to negotiate the direction in
            which text can be transmitted in a real-time text conversation.
          </t>
          <t>
          <aside pn="section-4.2.3-2">
            <t indent="0" pn="section-4.2.3-2.1">
            NOTE: A WebRTC data channel is always bi-directional. bidirectional. The usage of the 'dcsa'
            attribute only affects the direction in which implementations are allowed to
            transmit text on a T.140 data channel.
            </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
            for unicast streams defined in <xref target="RFC3264"/>, target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>, as described below.
            Note that the rules only apply to the direction attributes.
          </t>
          <t>
          <t indent="0" pn="section-4.2.3-4">
            Session-level direction attributes <xref target="I-D.ietf-mmusic-rfc4566bis"/> target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> have no impact
            on a T.140 data channel.
          </t>
          <section anchor="sec.sdp.dcsa.dir.neg.off" title="Generating an Offer">
              <t> numbered="true" toc="exclude" removeInRFC="false" pn="section-4.2.3.1">
            <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 data channel, it
                SHOULD
                <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 data channel, an
                implicit 'sendrecv' attribute inside a 'dcsa' attribute is applied by default.
            </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
                MUST
                <bcp14>MUST</bcp14> mark the data channel as sendonly with a 'sendonly' attribute inside a
                'dcsa' attribute.
            </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 channel, it
                MUST
                <bcp14>MUST</bcp14> mark the data channel as recvonly with a 'recvonly' attribute inside a
                'dcsa' attribute.
            </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.140 data channel, it
                MUST
                <bcp14>MUST</bcp14> mark the data channel as inactive with an 'inactive' attribute inside a
                'dcsa' attribute.
            </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
                explicitly mark the data channel) or recvonly, it MUST <bcp14>MUST</bcp14> be prepared to receive
                T.140 data as soon as the state of the T.140 data channel allows it.
            </t>
          </section>
          <section anchor="sec.sdp.dcsa.dir.neg.ans" title="Generating an Answer">
              <t> numbered="true" toc="exclude" removeInRFC="false" pn="section-4.2.3.2">
            <name slugifiedName="name-generating-an-answer">Generating an Answer</name>
            <t indent="0" pn="section-4.2.3.2-1">
                When the answerer accepts an offer, offer and marks the direction of the text
                in the corresponding answer, the direction is based on the marking (or the lack
                of explicit marking) in the offer.
            </t>
              <t>
            <t indent="0" pn="section-4.2.3.2-2">
                If the offerer either explicitly marked the data channel as sendrecv, sendrecv or if the offerer did not mark
                the data channel, the answerer SHOULD <bcp14>SHOULD</bcp14> mark the data channel as sendrecv, sendonly, recvonly recvonly, or inactive
                with a 'sendrecv', 'sendonly', 'recvonly' 'recvonly', or 'inactive' attribute respectively attribute, respectively,
                inside a 'dcsa' attribute. If the answerer does not explicitly mark the data channel, an
                implicit 'sendrecv' attribute inside a 'dcsa' attribute is applied by default.
            </t>
              <t>
            <t indent="0" pn="section-4.2.3.2-3">
                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
                'inactive' attribute respectively attribute, respectively, inside a 'dcsa' attribute.
            </t>
              <t>
            <t indent="0" pn="section-4.2.3.2-4">
                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
                'inactive' attribute respectively attribute, respectively, inside a 'dcsa' attribute.
            </t>
              <t>
            <t indent="0" pn="section-4.2.3.2-5">
                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 inside a
                'dcsa' attribute.
            </t>
              <t>
            <t indent="0" pn="section-4.2.3.2-6">
                If the answerer has marked a data channel as sendrecv or recvonly, it MUST <bcp14>MUST</bcp14> be
                prepared to receive data as soon as the state of the T.140 data channel allows
                transmission of data.
            </t>
          </section>
          <section anchor="sec.sdp.dcsa.dir.neg.rec" title="Offerer numbered="true" toc="exclude" removeInRFC="false" pn="section-4.2.3.3">
            <name slugifiedName="name-offerer-receiving-an-answer">Offerer Receiving an Answer">
              <t> Answer</name>
            <t indent="0" pn="section-4.2.3.3-1">
                When the offerer receives an answer to the offer and the answerer has marked a
                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 data as soon as
                the state of the T.140 data channel allows it. If the answerer has marked the
                data channel as inactive or sendonly, the offerer MUST NOT <bcp14>MUST NOT</bcp14> send any T.140 data.
            </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 channel in accordance
                with the procedures above, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
                that the offerer does not process that scenario
                as an error situation, situation but rather assume that the answerer might both send and
                receive T.140 data on the data channel.
            </t>
          </section>
          <section anchor="sec.sdp.dcsa.dir.mod" title="Modify numbered="true" toc="exclude" removeInRFC="false" pn="section-4.2.3.4">
            <name slugifiedName="name-modifying-the-text-directio">Modifying the Text Direction">
            <t> Direction</name>
            <t indent="0" pn="section-4.2.3.4-1">
              If an endpoint wishes to modify a previously negotiated text direction
              in an ongoing session, it MUST <bcp14>MUST</bcp14> initiate an offer that indicates the new
              direction, following the rules in <xref target="sec.sdp.dcsa.dir.neg.off"/>. target="sec.sdp.dcsa.dir.neg.off" format="default" sectionFormat="of" derivedContent="Section 4.2.3.1"/>.
              If the answerer accepts the offer offer, it follows the procedures in
              <xref target="sec.sdp.dcsa.dir.neg.ans"/>. target="sec.sdp.dcsa.dir.neg.ans" format="default" sectionFormat="of" derivedContent="Section 4.2.3.2"/>.
            </t>
          </section>
        </section>
      </section>
      <section anchor="sec.sdp.ex" title="Examples">
          <t> numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-examples">Examples</name>
        <t indent="0" pn="section-4.3-1">
            Below is an example of an m= "m=" section of an offer
            for a T.140 data channel offering real-time text
            conversation in Spanish and Esperanto, and an m= "m=" section
            in the associated answer accepting Esperanto. The maximum
            character transmission rate is set to 20. As the offerer and
            answerer have not explicitly indicated the real-time text
            direction, the default direction "sendrecv" applies.
        </t>
          <figure>
            <preamble></preamble>
            <artwork><![CDATA[

Offer:
        <sourcecode name="" type="sdp" markers="false" pn="section-4.3-2">Offer:

   m=application 911 UDP/DTLS/SCTP webrtc-datachannel
   c=IN IP6 2001:db8::3
   a=max-message-size:1000
   a=sctp-port 5000
   a=setup:actpass
   a=dcmap:2 label="ACME customer service";subprotocol="t140"
   a=dcsa:2 fmtp:t140 cps=20
   a=dcsa:2 hlang-send:es eo
   a=dcsa:2 hlang-recv:es eo

Answer:

   m=application 2004 UDP/DTLS/SCTP webrtc-datachannel
   c=IN IP6 2001:db8::1
   a=max-message-size:1000
   a=sctp-port 6000
   a=setup:passive
   a=dcmap:2 label="ACME customer service";subprotocol="t140"
   a=dcsa:2 fmtp:t140 cps=20
   a=dcsa:2 hlang-send:eo
   a=dcsa:2 hlang-recv:eo

            ]]></artwork>
          </figure>
          <t> hlang-recv:eo</sourcecode>
        <t indent="0" pn="section-4.3-3">
            Below is an example of an m= "m=" section of an offer
            for a T.140 data channel where the offerer wishes to
            only receive real-time text, and an m= "m=" section
            in the associated answer indicating that the answerer
            will only send real-time text. No maximum
            character transmission rate is indicated. No preference for
            the language to be used for the real-time text conversation
            is indicated.
        </t>
          <figure>
            <preamble></preamble>
            <artwork><![CDATA[

Offer:
        <sourcecode name="" type="sdp" markers="false" pn="section-4.3-4">Offer:

   m=application 1400 UDP/DTLS/SCTP webrtc-datachannel
   c=IN IP6 2001:db8::3
   a=max-message-size:1000
   a=sctp-port 5000
   a=setup:actpass
   a=dcmap:2 label="ACME customer service";subprotocol="t140"
   a=dcsa:2 recvonly

Answer:

   m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
   c=IN IP6 2001:db8::1
   a=max-message-size:1000
   a=sctp-port 6000
   a=setup:passive
   a=dcmap:2 label="ACME customer service";subprotocol="t140"
   a=dcsa:2 sendonly

            ]]></artwork>
          </figure> sendonly</sourcecode>
      </section>
    </section>
    <section anchor="sec.t140" title="T.140 Considerations"> numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-t140-considerations">T.140 Considerations</name>
      <section anchor="sec.t140.slf" title="Session Layer Functions">
          <t> numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-session-layer-functions">Session-Layer Functions</name>
        <t indent="0" pn="section-5.1-1">
            Section 6.1 of <xref target="T140"/> target="T140" format="default" sectionFormat="of" derivedContent="T140"/> describes the generic T.140 session
            control functions at a high-level high level, in a signalling protocol manner that is independent manner.
            of the signaling protocol. The list below describes how the functions
            are realized when using a T.140 data channel.
            <list style="symbols">
              <t>Prepare session: An
        </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-5.1-2">
          <dt pn="section-5.1-2.1">Prepare session:</dt>
          <dd pn="section-5.1-2.2">An endpoint can indicate its support of T.140 data channels
         using signalling specific signaling-specific means (e.g., using SIP OPTIONS <xref target="RFC3261"/>), target="RFC3261" format="default" sectionFormat="of" derivedContent="RFC3261"/>) or by indicating the support in an
         offer or answer (<xref target="sec.sdp"/>)</t>
              <t>Initiate session: An target="sec.sdp" format="default" sectionFormat="of" derivedContent="Section 4"/>).</dd>
          <dt pn="section-5.1-2.3">Initiate session:</dt>
          <dd pn="section-5.1-2.4">An offer is used to request the establishment of a
         T.140 data channel (<xref target="sec.sdp"/>)</t>
              <t>Accept session: An target="sec.sdp" format="default" sectionFormat="of" derivedContent="Section 4"/>).</dd>
          <dt pn="section-5.1-2.5">Accept session:</dt>
          <dd pn="section-5.1-2.6">An answer is used to accept a request to establish a
        T.140 data channel (<xref target="sec.sdp"/>)</t>
              <t>Deny session: An target="sec.sdp" format="default" sectionFormat="of" derivedContent="Section 4"/>).</dd>
          <dt pn="section-5.1-2.7">Deny session:</dt>
          <dd pn="section-5.1-2.8">An answer is used to reject a request to establish
        a T.140 data channel, using the generic procedures for rejecting
        a data channel <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/></t>
              <t>Disconnect session: An target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>.</dd>
          <dt pn="section-5.1-2.9">Disconnect session:</dt>
          <dd pn="section-5.1-2.10">An offer or answer is used to disable a previously
         established T.140 data channel, using the generic procedures for closing
         a data channel <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/></t>
              <t>Data: Data target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>.</dd>
          <dt pn="section-5.1-2.11">Data:</dt>
          <dd pn="section-5.1-2.12">Data is sent on an established T.140 data channel (<xref target="sec.t140.send"/>)</t>
            </list>
          </t> target="sec.t140.send" format="default" sectionFormat="of" derivedContent="Section 5.2"/>).</dd>
        </dl>
      </section>
      <section anchor="sec.t140.send" title="Data numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-data-encoding-and-sending">Data Encoding and Sending">
          <t> Sending</name>
        <t indent="0" pn="section-5.2-1">
            T.140 text is encoded and framed as T140blocks <xref target="RFC4103"/>.
          </t>
          <t> 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"/> target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960"/> used to
            realize the T.140 data channel using standard T.140 transmission procedures
            <xref target="T140"/>. target="T140" format="default" sectionFormat="of" derivedContent="T140"/>. One or more T140blocks can be sent in a single
            SCTP user message <xref target="RFC4960"/>. target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960"/>. Unlike RTP based RTP-based transport for
            real-time text <xref target="RFC4103"/>, target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>, T.140 data channels do not use redundant
            transmission of text. The reason for text; this is that because the T.140 data channel achieves
            robust transmission by using the "reliable" mode of the data channel.
        </t>
          <t>
            Data sending
        <t indent="0" pn="section-5.2-3">
            Data-sending procedures conform to <xref target="T140"/>.
          </t>
          <t> target="T140" format="default" sectionFormat="of" derivedContent="T140"/>.
        </t>
        <t indent="0" pn="section-5.2-4">
            See Section 8 of <xref target="T140"/> target="T140" format="default" sectionFormat="of" derivedContent="T140"/> for coding details.
        </t>
          <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 control
            codes for controlling the presentation which presentation; these control codes may not be supported by the
            presentation level of the receiving application. The receiving application
            is expected to handle reception of such T.140 control codes appropriately
            (e.g.
            (e.g., ignore and skip them) even if their effect on the presentation is not supported.
          </t>
        </aside>
      </section>
      <section anchor="sec.t140.buff" title="Data Buffering">
          <t> numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-data-buffering">Data Buffering</name>
        <t indent="0" pn="section-5.3-1">
            As described in <xref target="T140"/>, target="T140" format="default" sectionFormat="of" derivedContent="T140"/>, buffering can be used to reduce
            overhead, with the maximum assigned transmission interval of T140blocks
            from the buffer being 500 ms as long as there is text to send.
        </t>
          <t>
        <t indent="0" pn="section-5.3-2">
            Buffering MAY <bcp14>MAY</bcp14> also be used for staying within the maximum character
            transmission rate (<xref target="sec.sdp.dcsa"/>).
          </t>
          <t> target="sec.sdp.dcsa" format="default" sectionFormat="of" derivedContent="Section 4.2"/>).
        </t>
        <t indent="0" pn="section-5.3-3">
            An implementation needs to take the user requirements for smooth
            flow and low latency in real-time text conversation into consideration when
            assigning a transmission interval. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use the default transmission
            interval of 300 milliseconds ms <xref target="RFC4103"/>, target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>, for T.140 data channels.
            Implementers might also use lower values for specific applications requiring low latency,
            taking the increased overhead in into consideration.
        </t>
      </section>
      <section anchor="sec.t140.loss" title="Loss of T140blocks">
          <t> numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-loss-of-t140blocks">Loss of T140blocks</name>
        <t indent="0" pn="section-5.4-1">
            In the case of network failure or congestion, T.140 data channels might
            fail and get torn down.  If this happens but the session sustains, is sustained, it
            is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that implementations try to reestablish the T.140
            data channels. As a T.140 data channel does not provide a mechanism for
            the receiver to identify retransmitted T140blocks after channel
            reestablishment, the sending endpoint MUST NOT <bcp14>MUST NOT</bcp14> retransmit T140blocks.
            Similarly, a receiver SHOULD <bcp14>SHOULD</bcp14> indicate to the user
            that there has
            been a channel reestablishment, has been reestablished and that text might have been lost.
            This MAY <bcp14>MAY</bcp14> be done by inserting the missing text markers <xref target="T140ad1"/> target="T140ad1" format="default" sectionFormat="of" derivedContent="T140ad1"/>
            or in any other way evident to the user.
        </t>
          <t>
        <aside pn="section-5.4-2">
          <t indent="0" pn="section-5.4-2.1">
            NOTE: If the SCTP association <xref target="RFC4960"/> target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960"/> used to realize the T.140 data channel
            fails and gets torn down, it needs to be re-established reestablished before the T.140 data channel can be
            reestablished. The procedures after the reestablishment of After the T.140 data channel is reestablished, the
            procedures defined in this section apply no matter if apply, regardless of whether only the T.140
            data channel, channel or the whole SCTP association, association got torn down.
          </t>
        </aside>
      </section>
      <section anchor="sec.t140.mul" title="Multi-party Considerations">
          <t> numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-multi-party-considerations">Multi-party Considerations</name>
        <t indent="0" pn="section-5.5-1">
            If an implementation needs to support multi-party scenarios, the implementation needs
            to support multiple simultaneous T.140 data channels, one for each remote party. At
            the time of writing this document, this is true even in scenarios where each participant
            communicates via a centralized conference server. The reason This is that, because, unlike RTP media,
            WebRTC data channels and the T.140 protocol do not support the indication of the source
            of T.140 data. The 'label' attribute parameter in the SDP 'dcmap' attribute label attribute parameter (<xref target="sec.sdp.dcmap"/>) target="sec.sdp.dcmap" format="default" sectionFormat="of" derivedContent="Section 4.1"/>)
            can be used by the offerer to provide additional information about each T.140 data channel, channel and help
            implementations to distinguish between them.
        </t>
          <t>
        <aside pn="section-5.5-2">
          <t indent="0" pn="section-5.5-2.1">
            NOTE: Future extensions to T.140, T.140 or to the T140block, T140block might allow indicating 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
            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
            real-time text from one source at any given time, and e.g., time and, for example, include human readable human-readable text
            labels in the real-time text stream that indicate the source whenever the conference server
            switches the source. This would allow the receiver to present real-time text from different
            sources separately. The procedures of for such a mechanism are outside the scope of this document.
          </t>
        </aside>
      </section>
    </section>
    <section anchor="sec.gw" title="Gateway Considerations">
      <t> numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <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 for
        both packet-switched and circuit-switched networks. Many are based on the
        ITU-T T.140 protocol on at the application and presentation level levels <xref target="T140"/>. target="T140" format="default" sectionFormat="of" derivedContent="T140"/>.
        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.
      </t>
      <t>
      <t indent="0" pn="section-6-2">
        When performing interworking between T.140 data channels and real-time text
        in other transports and protocols, a number of factors need to be considered.
        At the time of writing this document, the most common IP-based real-time text transport
        is the RTP based RTP-based mechanism defined in <xref target="RFC4103"/>. target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>. While this document
        does not define a complete interworking solution, this the list below provides some guidance
        and considerations to take into account when designing a gateway for interworking
        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">
        <li pn="section-6-3.1">
            For each T.140 data channel channel, there is an RTP stream for real-time text <xref target="RFC4103"/>. target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>.
            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"/> target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>
            is set on it.
          </t>
          <t>
          </li>
        <li pn="section-6-3.2">
            During a normal text flow, T140blocks received from one network are forwarded towards the other network.
            Keep-alive
            Keepalive traffic is handled by lower layers on the T.140 data channel. A gateway might have to extract keep-alives keepalives from
            incoming RTP streams, streams and MAY <bcp14>MAY</bcp14> generate keep-alives keepalives on outgoing RTP streams.
          </t>
          <t>
          </li>
        <li pn="section-6-3.3">
            If the gateway detects or suspects loss of data on the RTP stream, stream and the lost data has not been
            retrieved using a redundancy mechanism, the gateway SHOULD <bcp14>SHOULD</bcp14> insert the T.140 missing text
            marker <xref target="T140ad1"/> target="T140ad1" format="default" sectionFormat="of" derivedContent="T140ad1"/> in the data sent on the outgoing T.140 data channel.
          </t>
          <t>
          </li>
        <li pn="section-6-3.4">
            If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished
            the gateway SHOULD <bcp14>SHOULD</bcp14> insert the T.140 missing text marker <xref target="T140ad1"/> target="T140ad1" format="default" sectionFormat="of" derivedContent="T140ad1"/> in the data sent on the outgoing RTP stream
            if it detects or suspects that data sent by the remote T.140 data channel endpoint was lost.
          </t>
          <t>
          </li>
        <li pn="section-6-3.5">
            If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel
            has been reestablished the gateway SHOULD <bcp14>SHOULD</bcp14> insert the T.140 missing text marker <xref target="T140ad1"/> target="T140ad1" format="default" sectionFormat="of" derivedContent="T140ad1"/> in the data
            sent on the outgoing T.140 data channel if it detects or suspects that data sent or to be sent on the
            T.140 data channel was lost during the failure.
          </t>
          <t>
          </li>
        <li pn="section-6-3.6">
            The gateway MUST <bcp14>MUST</bcp14> indicate the same text transmission direction (<xref target="sec.sdp.dcsa.dir"/>) target="sec.sdp.dcsa.dir" format="default" sectionFormat="of" derivedContent="Section 4.2.3"/>) on the T.140 data channel
            and the RTP stream.
          </t>
        </list>
      </t>
      <t>
          </li>
      </ul>
      <aside pn="section-6-4">
        <t indent="0" pn="section-6-4.1">
        NOTE: In order for the gateway to insert a missing text marker, marker or to perform other actions that require that the
        gateway has have access to the T.140 data, the T.140 data cannot be
        encrypted end-to-end 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.
        </t>
      </aside>
      <aside pn="section-6-5">
        <t indent="0" pn="section-6-5.1">NOTE: The guidance and considerations above 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 considerations.</t>
      </aside>
    </section>
    <section anchor="sec.8373" title="Update numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-update-to-rfc-8373">Update to RFC 8373">
        <t> 8373</name>
      <t indent="0" pn="section-7-1">
          This document updates RFC 8373 <xref target="RFC8373"/>, target="RFC8373" format="default" sectionFormat="of" derivedContent="RFC8373"/> by defining how the SDP hlang-send 'hlang-send' and hlang-recv 'hlang-recv' attributes are used for
          the "application/webrtc-datachannel" media type.
      </t>
        <t>
      <t indent="0" pn="section-7-2">
          SDP offerers and answerers MUST NOT <bcp14>MUST NOT</bcp14> include the attributes directly in the m= "m=" section associated with the
          'application/webrtc-datachannel'
          "application/webrtc-datachannel" media type. Instead, the attributes MUST <bcp14>MUST</bcp14> be associated with
          individual data channels, using the SDP 'dcsa' attribute. A specification that defines a subprotocol
          that uses the attributes MUST <bcp14>MUST</bcp14> specify the modality for that subprotocol, or how to retrieve the
          modality if the subprotocol supports multiple modalities. The subprotocol is indicated using the SDP
          'dcmap' attribute.
      </t>
    </section>
    <section anchor="sec.sec" title="Security Considerations">
        <t> numbered="true" toc="include" removeInRFC="false" 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
          <xref target="I-D.ietf-rtcweb-security-arch"/> target="RFC8826" format="default" sectionFormat="of" derivedContent="RFC8826"/> and <xref target="I-D.ietf-rtcweb-security"/>.
        </t>
        <t> target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC8827"/>.
      </t>
      <t indent="0" pn="section-8-2">
          The generic security considerations for WebRTC data channels
          are defined in <xref target="I-D.ietf-rtcweb-data-channel"/>. target="RFC8831" format="default" sectionFormat="of" derivedContent="RFC8831"/>. As data channels
          are always encrypted by design, the T.140 data channels will
          also be encrypted.
      </t>
        <t>
      <t indent="0" pn="section-8-3">
          The generic security considerations for negotiating data channels
          using the SDP-based external
          negotiation method SDP offer/answer mechanism are defined in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>. target="RFC8864" format="default" sectionFormat="of" derivedContent="RFC8864"/>.
          There are no additional security considerations specific to T.140 data channel specific security considerations. channels.
      </t>
        <t>
      <t indent="0" pn="section-8-4">
          When performing interworking between T.140 data channels and real-time text and
          the RTP based mechanism defined in
          RTP-based T.140 transport <xref target="RFC4103"/>, target="RFC4103" format="default" sectionFormat="of" derivedContent="RFC4103"/>, in order for a gateway to
          insert a missing text marker, marker or to perform other actions that require that the
          gateway has have access to the T.140 data, the T.140 data cannot be
          encrypted end-to-end end to end
          between the T.140 data channel endpoint and the RTP endpoint.
      </t>
    </section>
    <section anchor="sec.iana" title="IANA considerations">
      <t>
        [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the RFC number of this document.]
      </t> numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="sec.iana.sub" title="Subprotocol numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-subprotocol-identifier-t140">Subprotocol Identifier t140">
        <t>
          This document adds "t140"</name>
        <t indent="0" pn="section-9.1-1">
          Per this document, the subprotocol identifier "t140" to the has been added
          to the "WebSocket Subprotocol Name Registry" as follows:
        </t>
        <texttable title="">
          <ttcol align='left' width='30%'/>
          <ttcol align='left'/>

          <c>Subprotocol Identifier:</c>
          <c>t140</c>

          <c>Subprotocol
        <dl newline="false" spacing="normal" indent="3" pn="section-9.1-2">
          <dt pn="section-9.1-2.1">Subprotocol Identifier:</dt>
          <dd pn="section-9.1-2.2">t140</dd>
          <dt pn="section-9.1-2.3">Subprotocol Common Name:</c>
          <c>ITU-T Name:</dt>
          <dd pn="section-9.1-2.4">ITU-T T.140 Real-Time Text</c>

          <c>Subprotocol Definition:</c>
          <c>RFCXXXX</c>

          <c>Reference:</c>
          <c>RFCXXXX</c>
        </texttable> Text</dd>
          <dt pn="section-9.1-2.5">Subprotocol Definition:</dt>
          <dd pn="section-9.1-2.6">RFC 8865</dd>
          <dt pn="section-9.1-2.7">Reference:</dt>
          <dd pn="section-9.1-2.8">RFC 8865</dd>
        </dl>
      </section>
      <section title="SDP fmtp Attribute" anchor="sec.iana.dcsa.fmtp">
        <t> anchor="sec.iana.dcsa.fmtp" numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <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 attribute is
          included in an SDP 'dcsa' attribute and associated with an a T.140 real-time text session
          over a WebRTC data channel.
 The usage is defined in <xref target="sec.sdp.dcsa.trans"/>.
        </t>
        <t> target="sec.sdp.dcsa.trans" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>.
        </t>
        <t indent="0" pn="section-9.2-2">
          The usage level "dcsa(t140)" is "dcsa (t140)" has been added to the registration of the SDP 'fmtp' attribute in the Session "Session Description
          Protocol (SDP) Parameters Parameters" registry as follows:
        </t>
        <texttable title="">
          <ttcol align='left' width='35%'/>
          <ttcol align='left' width='65%'/>

          <c>Contact name:</c>
          <c>IESG</c>

          <c>Contact email:</c>
          <c>iesg@ietf.org</c>

          <c>Attribute name:</c>
          <c>fmtp</c>

          <c>Usage level:</c>
          <c>dcsa(t140)</c>

          <c>Purpose:</c>
          <c>
            Indicate
        <dl newline="false" spacing="normal" indent="3" pn="section-9.2-3">
          <dt pn="section-9.2-3.1">Contact name:</dt>
          <dd pn="section-9.2-3.2">IESG</dd>
          <dt pn="section-9.2-3.3">Contact email:</dt>
          <dd pn="section-9.2-3.4">iesg@ietf.org</dd>
          <dt pn="section-9.2-3.5">Attribute name:</dt>
          <dd pn="section-9.2-3.6">fmtp</dd>
          <dt pn="section-9.2-3.7">Usage level:</dt>
          <dd pn="section-9.2-3.8">dcsa (t140)</dd>
          <dt pn="section-9.2-3.9">Purpose:</dt>
          <dd pn="section-9.2-3.10">Indicate format parameters for a T.140 data channel, such as maximum character transmission rates.
          </c>

          <c>Reference:</c>
          <c>RFCXXXX</c>
        </texttable> rates.</dd>
          <dt pn="section-9.2-3.11">Reference:</dt>
          <dd pn="section-9.2-3.12">RFC 8865</dd>
        </dl>
      </section>
      <section title="SDP anchor="sec.iana.dcsa.hlang" numbered="true" toc="include" removeInRFC="false" pn="section-9.3">
        <name slugifiedName="name-sdp-language-attributes">SDP Language Attributes" anchor="sec.iana.dcsa.hlang">
        <t> Attributes</name>
        <t indent="0" pn="section-9.3-1">
          This document modifies the usage of the SDP 'hlang-send' and 'hlang-recv' attributes, if these attributes are
          included in SDP 'dcsa' attributes associated with an a T.140 data channel.
          The modified usage is described in <xref target="sec.sdp.dcsa.lan"/>.
        </t>
        <t> target="sec.sdp.dcsa.lan" format="default" sectionFormat="of" derivedContent="Section 4.2.2"/>.
        </t>
        <t indent="0" pn="section-9.3-2">
          The usage level "dcsa(t140)" is "dcsa (t140)" has been added to the registration of the SDP 'hland-send' 'hlang-send' attribute in the Session "Session Description
          Protocol (SDP) Parameters Parameters" registry as follows:
        </t>
        <texttable title="">
          <ttcol align='left' width='35%'/>
          <ttcol align='left' width='65%'/>

          <c>Contact name:</c>
          <c>IESG</c>

          <c>Contact email:</c>
          <c>iesg@ietf.org</c>

          <c>Attribute name:</c>
          <c>hlang-send</c>

          <c>Usage level:</c>
          <c>dcsa(t140)</c>

          <c>Purpose:</c>
          <c>
            Negotiate
        <dl newline="false" spacing="normal" indent="3" pn="section-9.3-3">
          <dt pn="section-9.3-3.1">Contact name:</dt>
          <dd pn="section-9.3-3.2">IESG</dd>
          <dt pn="section-9.3-3.3">Contact email:</dt>
          <dd pn="section-9.3-3.4">iesg@ietf.org</dd>
          <dt pn="section-9.3-3.5">Attribute name:</dt>
          <dd pn="section-9.3-3.6">hlang-send</dd>
          <dt pn="section-9.3-3.7">Usage level:</dt>
          <dd pn="section-9.3-3.8">dcsa (t140)</dd>
          <dt pn="section-9.3-3.9">Purpose:</dt>
          <dd pn="section-9.3-3.10">Negotiate the language to be used on a T.140 data channel.
          </c>

          <c>Reference:</c>
          <c>RFCXXXX</c>
        </texttable>
        <t> channel.</dd>
          <dt pn="section-9.3-3.11">Reference:</dt>
          <dd pn="section-9.3-3.12">RFC 8865</dd>
        </dl>
        <t indent="0" pn="section-9.3-4">
          The usage level "dcsa(t140)" is "dcsa (t140)" has been added to the registration of the SDP 'hland-recv' 'hlang-recv' attribute in the Session "Session Description
          Protocol (SDP) Parameters Parameters" registry as follows:
        </t>
        <texttable title="">
          <ttcol align='left' width='35%'/>
          <ttcol align='left' width='65%'/>

          <c>Contact name:</c>
          <c>IESG</c>

          <c>Contact email:</c>
          <c>iesg@ietf.org</c>

          <c>Attribute name:</c>
          <c>hlang-recv</c>

          <c>Usage level:</c>
          <c>dcsa(t140)</c>

          <c>Purpose:</c>
          <c>
            Negotiate
        <dl newline="false" spacing="normal" indent="3" pn="section-9.3-5">
          <dt pn="section-9.3-5.1">Contact name:</dt>
          <dd pn="section-9.3-5.2">IESG</dd>
          <dt pn="section-9.3-5.3">Contact email:</dt>
          <dd pn="section-9.3-5.4">iesg@ietf.org</dd>
          <dt pn="section-9.3-5.5">Attribute name:</dt>
          <dd pn="section-9.3-5.6">hlang-recv</dd>
          <dt pn="section-9.3-5.7">Usage level:</dt>
          <dd pn="section-9.3-5.8">dcsa (t140)</dd>
          <dt pn="section-9.3-5.9">Purpose:</dt>
          <dd pn="section-9.3-5.10">Negotiate the language to be used on a T.140 data channel.
          </c>

          <c>Reference:</c>
          <c>RFCXXXX</c>
        </texttable> channel.</dd>
          <dt pn="section-9.3-5.11">Reference:</dt>
          <dd pn="section-9.3-5.12">RFC 8865</dd>
        </dl>
      </section>
      <section title="SDP anchor="sec.iana.dcsa.direction" numbered="true" toc="include" removeInRFC="false" pn="section-9.4">
        <name slugifiedName="name-sdp-media-direction-attribu">SDP Media Direction Attributes" anchor="sec.iana.dcsa.direction">
        <t> Attributes</name>
        <t indent="0" pn="section-9.4-1">
          This document modifies the usage of the SDP 'sendonly', 'recvonly', 'sendrecv' 'sendrecv', and 'inactive' attributes,
          if these attributes are included in SDP 'dcsa' attributes associated
          with a T.140 data channel. The modified usage
          is described in <xref target="sec.sdp.dcsa.dir"/>.
        </t>
        <t> target="sec.sdp.dcsa.dir" format="default" sectionFormat="of" derivedContent="Section 4.2.3"/>.
        </t>
        <t indent="0" pn="section-9.4-2">
          The usage level "dcsa(t140)" is "dcsa (t140)" has been added to the registration of the SDP 'sendonly' attribute in the Session "Session Description
          Protocol (SDP) Parameters Parameters" registry as follows:
        </t>
        <texttable title="">
          <ttcol align='left' width='35%'/>
          <ttcol align='left' width='65%'/>

          <c>Contact name:</c>
          <c>IESG</c>

          <c>Contact email:</c>
          <c>iesg@ietf.org</c>

          <c>Attribute name:</c>
          <c>sendonly</c>

          <c>Usage level:</c>
          <c>dcsa(t140)</c>

          <c>Purpose:</c>
          <c>
            Negotiate
        <dl newline="false" spacing="normal" indent="3" pn="section-9.4-3">
          <dt pn="section-9.4-3.1">Contact name:</dt>
          <dd pn="section-9.4-3.2">IESG</dd>
          <dt pn="section-9.4-3.3">Contact email:</dt>
          <dd pn="section-9.4-3.4">iesg@ietf.org</dd>
          <dt pn="section-9.4-3.5">Attribute name:</dt>
          <dd pn="section-9.4-3.6">sendonly</dd>
          <dt pn="section-9.4-3.7">Usage level:</dt>
          <dd pn="section-9.4-3.8">dcsa (t140)</dd>
          <dt pn="section-9.4-3.9">Purpose:</dt>
          <dd pn="section-9.4-3.10">Negotiate the direction in which real-time text can be sent on a T.140 data channel.
          </c>

          <c>Reference:</c>
          <c>RFCXXXX</c>
        </texttable>

        <t> channel.</dd>
          <dt pn="section-9.4-3.11">Reference:</dt>
          <dd pn="section-9.4-3.12">RFC 8865</dd>
        </dl>
        <t indent="0" pn="section-9.4-4">
          The usage level "dcsa(t140)" is "dcsa (t140)" has been added to the registration of the SDP 'recvonly' attribute in the Session "Session Description
          Protocol (SDP) Parameters Parameters" registry as follows:
        </t>
        <texttable title="">
          <ttcol align='left' width='35%'/>
          <ttcol align='left' width='65%'/>

          <c>Contact name:</c>
          <c>IESG</c>

          <c>Contact email:</c>
          <c>iesg@ietf.org</c>

          <c>Attribute name:</c>
          <c>recvonly</c>

          <c>Usage level:</c>
          <c>dcsa(t140)</c>

          <c>Purpose:</c>
          <c>
            Negotiate
        <dl newline="false" spacing="normal" indent="3" pn="section-9.4-5">
          <dt pn="section-9.4-5.1">Contact name:</dt>
          <dd pn="section-9.4-5.2">IESG</dd>
          <dt pn="section-9.4-5.3">Contact email:</dt>
          <dd pn="section-9.4-5.4">iesg@ietf.org</dd>
          <dt pn="section-9.4-5.5">Attribute name:</dt>
          <dd pn="section-9.4-5.6">recvonly</dd>
          <dt pn="section-9.4-5.7">Usage level:</dt>
          <dd pn="section-9.4-5.8">dcsa (t140)</dd>
          <dt pn="section-9.4-5.9">Purpose:</dt>
          <dd pn="section-9.4-5.10">Negotiate the direction in which real-time text can be sent on a T.140 data channel.
          </c>

          <c>Reference:</c>
          <c>RFCXXXX</c>
        </texttable>
        <t> channel.</dd>
          <dt pn="section-9.4-5.11">Reference:</dt>
          <dd pn="section-9.4-5.12">RFC 8865</dd>
        </dl>
        <t indent="0" pn="section-9.4-6">
          The usage level "dcsa(t140)" is "dcsa (t140)" has been added to the registration of the SDP 'sendrecv' attribute in the Session "Session Description
          Protocol (SDP) Parameters Parameters" registry as follows:
        </t>
        <texttable title="">
          <ttcol align='left' width='35%'/>
          <ttcol align='left' width='65%'/>

          <c>Contact name:</c>
          <c>IESG</c>

          <c>Contact email:</c>
          <c>iesg@ietf.org</c>

          <c>Attribute name:</c>
          <c>sendrecv</c>

          <c>Usage level:</c>
          <c>dcsa(t140)</c>

          <c>Purpose:</c>
          <c>
            Negotiate
        <dl newline="false" spacing="normal" indent="3" pn="section-9.4-7">
          <dt pn="section-9.4-7.1">Contact name:</dt>
          <dd pn="section-9.4-7.2">IESG</dd>
          <dt pn="section-9.4-7.3">Contact email:</dt>
          <dd pn="section-9.4-7.4">iesg@ietf.org</dd>
          <dt pn="section-9.4-7.5">Attribute name:</dt>
          <dd pn="section-9.4-7.6">sendrecv</dd>
          <dt pn="section-9.4-7.7">Usage level:</dt>
          <dd pn="section-9.4-7.8">dcsa (t140)</dd>
          <dt pn="section-9.4-7.9">Purpose:</dt>
          <dd pn="section-9.4-7.10">Negotiate the direction in which real-time text can be sent on a T.140 data channel.
          </c>

          <c>Reference:</c>
          <c>RFCXXXX</c>
        </texttable>
        <t> channel.</dd>
          <dt pn="section-9.4-7.11">Reference:</dt>
          <dd pn="section-9.4-7.12">RFC 8865</dd>
        </dl>
        <t indent="0" pn="section-9.4-8">
          The usage level "dcsa(t140)" is "dcsa (t140)" has been added to the registration of the SDP 'inactive' attribute in the Session "Session Description
          Protocol (SDP) Parameters Parameters" registry as follows:
        </t>
        <texttable title="">
          <ttcol align='left' width='35%'/>
          <ttcol align='left' width='65%'/>

          <c>Contact name:</c>
          <c>IESG</c>

          <c>Contact email:</c>
          <c>iesg@ietf.org</c>

          <c>Attribute name:</c>
          <c>inactive</c>

          <c>Usage level:</c>
          <c>dcsa(t140)</c>

          <c>Purpose:</c>
          <c>
            Negotiate
        <dl newline="false" spacing="normal" indent="3" pn="section-9.4-9">
          <dt pn="section-9.4-9.1">Contact name:</dt>
          <dd pn="section-9.4-9.2">IESG</dd>
          <dt pn="section-9.4-9.3">Contact email:</dt>
          <dd pn="section-9.4-9.4">iesg@ietf.org</dd>
          <dt pn="section-9.4-9.5">Attribute name:</dt>
          <dd pn="section-9.4-9.6">inactive</dd>
          <dt pn="section-9.4-9.7">Usage level:</dt>
          <dd pn="section-9.4-9.8">dcsa (t140)</dd>
          <dt pn="section-9.4-9.9">Purpose:</dt>
          <dd pn="section-9.4-9.10">Negotiate the direction in which real-time text can be sent on a T.140 data channel.
          </c>

          <c>Reference:</c>
          <c>RFCXXXX</c>
        </texttable> channel.</dd>
          <dt pn="section-9.4-9.11">Reference:</dt>
          <dd pn="section-9.4-9.12">RFC 8865</dd>
        </dl>
      </section>
    </section>

    <section anchor="sec.acks" title="Acknowledgements" toc="default">
      <t>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document is based on defines these words as they should be interpreted in IETF documents.  This document specifies an earlier Internet draft edited Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3264" quoteTitle="true" derivedAnchor="RFC3264">
          <front>
            <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t indent="0">This document defines a mechanism by Keith Drage,
        Juergen Stoetzer-Bradler and Albrecht Schwarz.
      </t>
      <t>
        Thomas Belling provided useful comments on which two entities can make use of the initial (pre-submission) version Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.  In the model, one participant offers the other a description of the draft. Paul Kyzivat desired session from their perspective, and Bernard Aboba provided comments on the draft.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.3264"?>
      <?rfc include="reference.RFC.4103"?>
      <?rfc include="reference.RFC.4960"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.8373"?>
      <?rfc include='reference.I-D.ietf-mmusic-rfc4566bis'?>
      <?rfc include='reference.I-D.ietf-rtcweb-data-channel'?>
      <?rfc include='reference.I-D.ietf-mmusic-data-channel-sdpneg'?>
      <?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>
      <?rfc include='reference.I-D.ietf-rtcweb-security'?>
      <reference anchor="T140">
        <front>
          <title>Recommendation ITU-T T.140 (02/1998), Protocol other participant answers with the desired session from their perspective.  This offer/answer model is most useful in unicast sessions where information from both participants is needed for
             multimedia application text conversation</title>
          <author><organization>ITU-T</organization></author>
          <date year="1998" month="February"/> the complete view of the session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        <format type="HTML" target="https://www.itu.int/rec/T-REC-T.140-199802-I/en"/>
          <seriesInfo name="RFC" value="3264"/>
          <seriesInfo name="DOI" value="10.17487/RFC3264"/>
        </reference>
        <reference anchor="T140ad1"> anchor="RFC4103" target="https://www.rfc-editor.org/info/rfc4103" quoteTitle="true" derivedAnchor="RFC4103">
          <front>
          <title>Recommendation ITU-T.140 Addendum 1 - (02/2000), Protocol
            <title>RTP Payload for
             multimedia application text conversation</title>
          <author><organization>ITU-T</organization></author> 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="2000" month="February"/>
        </front>
        <format type="HTML" target="https://www.itu.int/rec/T-REC-T.140-200002-I!Add1/en"/>
      </reference>
    </references>
    <references title="Informative References">
      <?rfc include="reference.RFC.3261"?>
      <?rfc include="reference.RFC.3550"?>
      <?rfc include='reference.I-D.ietf-rtcweb-data-protocol'?>
    </references> year="2005" month="June"/>
            <abstract>
              <t indent="0">This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets.  Text conversation session contents are specified in ITU-T Recommendation T.140.</t>
              <t indent="0">One payload format is described for transmitting text 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 risk 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/rfc4566" 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 session announcement, session invitation, and other forms of multimedia session initiation.  [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/rfc4960" 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 describes the Stream Control Transmission Protocol (SCTP).  SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t>
              <t indent="0">SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP.  It offers the following services 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 multiple streams, with an option for order-of-arrival delivery of individual user messages,</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.  [STANDARDS-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/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <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 clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</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/rfc8373" 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 needs, abilities, and preferences regarding spoken, written, and signed languages. This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party.  This is especially important 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 operator 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 solution 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/rfc8826" 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/rfc8827" 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/rfc8831" 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/rfc8864" quoteTitle="true" derivedAnchor="RFC8864">
          <front>
            <title>Negotiation Data Channels Using the Session Description Protocol (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="editor">
              <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-199802-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 multimedia 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/rfc3261" 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 include 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/rfc3550" 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 transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation 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 provide 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 governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session 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/rfc8832" 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>
    <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 fullname="Keith Drage"/>,
        <contact fullname="Juergen Stoetzer-Bradler"/>, and <contact fullname="Albrecht Schwarz"/>.
      </t>
      <t indent="0" pn="section-appendix.a-2">
        <contact fullname="Thomas Belling"/> provided useful comments on the initial (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 Communication</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>
</rfc>