rfc8865xml2.original.xml   rfc8865.xml 
<?xml version="1.0" encoding="windows-1252"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<?rfc subcompact="yes" ?> category="std" docName="draft-ietf-mmusic-t140-usage-data-channel-14"
<?rfc sortrefs="no" ?> number="8865" obsoletes="" updates="8373" submissionType="IETF"
<?rfc strict="yes" ?> consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" version="3
<rfc ipr="trust200902" category="std" docName="draft-ietf-mmusic-t140-usage-data ">
-channel-14" obsoletes="" updates="8373" submissionType="IETF" xml:lang="en"> <!-- xml2rfc v2v3 conversion 2.45.2 -->
<front> <front>
<title abbrev="T.140 Data Channel"> <title abbrev="T.140 Data Channel">
T.140 Real-time Text Conversation over WebRTC Data Channels T.140 Real-Time Text Conversation over WebRTC Data Channels
</title> </title>
<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
<seriesInfo name="RFC" value="8865"/>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<code>02420</code> <code>02420</code>
<city>Jorvas</city> <city>Jorvas</city>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>christer.holmberg@ericsson.com</email> <email>christer.holmberg@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="G.H." surname="Hellstrom" fullname="Gunnar Hellstrom"> <author initials="G." surname="Hellström" fullname="Gunnar Hellström">
<organization>Gunnar Hellstrom Accessible Communication</organization> <organization>Gunnar Hellström Accessible Communication</organization>
<address> <address>
<postal> <postal>
<street>Esplanaden 30</street> <street>Esplanaden 30</street>
<code>136 70</code> <code>136 70</code>
<city>Vendelso</city> <city>Vendelsö</city>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>gunnar.hellstrom@ghaccess.se</email> <email>gunnar.hellstrom@ghaccess.se</email>
</address> </address>
</author> </author>
<date month="September" year="2020"/>
<date year="2020"/>
<area>Transport</area>
<workgroup>MMUSIC Working Group</workgroup>
<keyword>SDP</keyword> <keyword>SDP</keyword>
<keyword>ITU-T</keyword> <keyword>ITU-T</keyword>
<keyword>T.140</keyword> <keyword>T.140</keyword>
<keyword>Data Channel</keyword> <keyword>Data Channel</keyword>
<keyword>WebRTC</keyword> <keyword>WebRTC</keyword>
<keyword>real-time text</keyword> <keyword>real-time text</keyword>
<abstract> <abstract>
<t> <t>
This document specifies how a WebRTC data channel can be used as a This document specifies how a Web Real-Time Communication (WebRTC) data
transport mechanism for Real-time text using the ITU-T Protocol for mult channel can be used as a
imedia transport mechanism for real-time text using the ITU-T Protocol for mult
application text conversation (Recommendation ITU-T T.140), and imedia
how the SDP offer/answer mechanism can be used to negotiate application text conversation (Recommendation ITU-T T.140) and
such data channel, referred to as T.140 data channel. This document upda how the Session Description Protocol (SDP) offer/answer mechanism can be
tes used to negotiate
such a data channel, referred to as a T.140 data channel. This document
updates
RFC 8373 to specify its use with WebRTC data channels. RFC 8373 to specify its use with WebRTC data channels.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" toc="default"> <section toc="default" numbered="true">
<name>Introduction</name>
<t> <t>
The ITU-T Protocol for multimedia application text conversation (Recomme ndation ITU-T T.140) The ITU-T Protocol for multimedia application text conversation (Recomme ndation ITU-T T.140)
<xref target="T140"/> defines a protocol for text conversation, also kno <xref target="T140" format="default"/> defines a protocol for text conve
wn as rsation, also known as
real-time text. The transport used for IP networks is the "RTP Payload f real-time text. The transport used for IP networks is the "RTP Payload
or Text Conversation" for Text Conversation" mechanism <xref target="RFC4103" format="default"
<xref target="RFC4103"/> mechanism, based on the Real-time Transport Pro />, based on the Real-time Transport Protocol (RTP) <xref target="RFC3550" forma
tocol (RTP) <xref target="RFC3550"/>. t="default"/>.
</t> </t>
<t> <t>
This document specifies how a WebRTC data channel <xref target="I-D.ietf This document specifies how a Web Real-Time Communication (WebRTC) data
-rtcweb-data-channel"/> channel <xref target="RFC8831"/>
can be used as a transport mechanism for T.140, and how the SDP offer/an can be used as a transport mechanism for T.140 and how the Session
swer mechanism Description Protocol (SDP) offer/answer mechanism
for data channels <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> c for data channels <xref target="RFC8864"/> can be used to negotiate such
an be used to negotiate such a data channel. a data channel.
</t> </t>
<t> <t>
In this document, a T.140 data channel refers to a WebRTC data channel f or which In this document, a T.140 data channel refers to a WebRTC data channel f or which
the instantiated sub-protocol is "t140", and where the channel is negoti the instantiated subprotocol is "t140" and where the channel is negotiat
ated ed
using the SDP-based external negotiation method <xref target="I-D.ietf-m using the SDP offer/answer mechanism <xref
music-data-channel-sdpneg"/>. target="RFC8864"/>.
</t>
<t>
NOTE: The decision to transport real-time text using a WebRTC data chann
el,
instead of using RTP based transport <xref target="RFC4103"/>,
is motivated by use-case "U-C 5: Real-time text chat during an audio
and/or video call with an individual or with multiple people in a confer
ence",
see Section 3.2 of <xref target="I-D.ietf-rtcweb-data-channel"/>.
</t> </t>
<!-- The "U-C 5" text is DNE. -->
<aside><t>
NOTE: The decision to transport real-time text using a WebRTC data chann
el
instead of using RTP-based transport <xref target="RFC4103" format="defa
ult"/>
is motivated by use case "U-C 5: Real-time text chat during an audio
and/or video call with an individual or with multiple people in a confer
ence";
see <xref target="RFC8831" sectionFormat="of" section="3.2"/>.
</t></aside>
<t> <t>
The brief notation "T.140" is used as a name for the text The brief notation "T.140" is used as a name for the text
conversation protocol according to <xref target="T140"/>. conversation protocol according to <xref target="T140" format="default"/ >.
</t> </t>
<t> <t>
Real-time text is intended to be entered by human users from a keyboard, Real-time text is intended to be entered by human users via a keyboard,
handwriting recognition, voice recognition or any other input method. handwriting recognition, voice recognition, or any other input method.
The rate of character entry is usually at a level of a few characters The rate of character entry is usually at a level of a few characters
per second or less. per second or less.
</t> </t>
<t> <t>
<xref target="sec.webrtc.cons"/> defines the generic data channel proper <xref target="sec.webrtc.cons" format="default"/> defines the generic da
ties for ta channel properties for
a T.140 data channel, and <xref target="sec.sdp"/> defines how they are a T.140 data channel, and <xref target="sec.sdp" format="default"/> defi
conveyed nes how they are conveyed
in an SDP dcmap attribute. While this document defines how to establish in an SDP 'dcmap' attribute. While this document defines how to negotiat
a e a
T.140 data channel using the SDP-based external negotiation method T.140 data channel using the SDP offer/answer mechanism
<xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>, the generic T.140 <xref target="RFC8864"/>, the generic T.140 and gateway
and gateway considerations defined in Sections&nbsp;<xref target="sec.webrtc.cons" f
considerations defined in <xref target="sec.webrtc.cons"/>, <xref target ormat="counter"/>, <xref target="sec.t140" format="counter"/>,
="sec.t140"/> and <xref target="sec.gw" format="counter"/> of this document can also b
and <xref target="sec.gw"/> of this document can also be applied when a e applied when a T.140 data channel
T.140 data channel
is established using another mechanism (e.g., the mechanism defined in is established using another mechanism (e.g., the mechanism defined in
<xref target="I-D.ietf-rtcweb-data-protocol"/>). Section 5 of <xref target="RFC8832"/>). <xref target="RFC8864" sectionFormat="of" sec
<xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> defines the mapping tion="5"/>
between the defines the mapping between the
SDP dcmap attribute parameters and the protocol parameters used in SDP 'dcmap' attribute parameters and the protocol parameters used in
<xref target="I-D.ietf-rtcweb-data-protocol"/>. <xref target="RFC8832"/>.
</t> </t>
<t> <t>
This document updates <xref target="RFC8373"/>, by defining how the SDP This document updates <xref target="RFC8373" format="default"/> by defin
hlang-send and hlang-recv attributes are used for the "application/webrt ing how the SDP
c-datachannel" 'hlang-send' and 'hlang-recv' attributes are used for the "application/w
ebrtc-datachannel"
media type. media type.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Conventions"> <name>Conventions</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"></xref> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
when, and only when, they appear in all capitals, as shown here. are to be interpreted as described in BCP&nbsp;14
</t> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="sec.webrtc.cons" numbered="true" toc="default">
<section anchor="sec.webrtc.cons" title="WebRTC Data Channel Considerations" <name>WebRTC Data Channel Considerations</name>
>
<t> <t>
The following WebRTC data channel property values <xref target="I-D.ietf -rtcweb-data-channel"/> The following WebRTC data channel property values <xref target="RFC8831" />
apply to a T.140 data channel: apply to a T.140 data channel:
</t> </t>
<texttable title=""> <table align="center">
<ttcol align='left' width='30%'/> <tbody>
<ttcol align='left'/> <tr>
<td align="left">Subprotocol Identifier</td>
<c>Subprotocol Identifier</c> <td align="left">t140</td>
<c>t140</c> </tr>
<tr>
<c>Transmission reliability</c> <td align="left">Transmission reliability</td>
<c>reliable</c> <td align="left">reliable</td>
</tr>
<c>Transmission order</c> <tr>
<c>in-order</c> <td align="left">Transmission order</td>
<td align="left">in-order</td>
<c>Label</c> </tr>
<c>See <xref target="sec.sdp.dcmap"/> and <xref target="sec.gw"/></c> <tr>
</texttable> <td align="left">Label</td>
<t> <td align="left">See <xref target="sec.sdp.dcmap"/></td>
</tr>
</tbody>
</table>
<aside><t>
NOTE: T.140 requires the transport channel to provide transmission of re al-time text without NOTE: T.140 requires the transport channel to provide transmission of re al-time text without
duplication and in original order. Therefore, T.140 does not specify rel iable and ordered duplication and in original order. Therefore, T.140 does not specify rel iable and ordered
transmission of T.140 data on the application layer. Instead, when RTP b ased transport is used, transmission of T.140 data on the application layer. Instead, when RTP-b ased transport is used,
the RTP sequence number is used to detect packet loss and out-of-order p ackets, and a redundancy the RTP sequence number is used to detect packet loss and out-of-order p ackets, and a redundancy
mechanism is used to achieve reliable delivery of T.140 data. By using mechanism is used to achieve reliable delivery of T.140 data. By using
the WebRTC data channel reliable and in-order transmission features <xre f target="I-D.ietf-rtcweb-data-channel"/> the WebRTC data channel's reliable and in-order transmission features <x ref target="RFC8831"/>
for the T.140 data channel, there is no need for a redundancy mechanism or a mechanism to detect for the T.140 data channel, there is no need for a redundancy mechanism or a mechanism to detect
data loss and out-of-order delivery at the application level. The latenc y characteristics of the data loss and out-of-order delivery at the application level. The latenc y characteristics of the
T.140 data channel is also regarded to be sufficient to meet the applica T.140 data channel are also regarded as sufficient to meet the applicati
tion requirements of T.140. on requirements of T.140.
</t> </t></aside>
</section> </section>
<section anchor="sec.sdp" numbered="true" toc="default">
<section anchor="sec.sdp" title="SDP Considerations"> <name>SDP Considerations</name>
<t> <t>
The generic SDP considerations, including the SDP Offer/Answer procedure The generic SDP considerations, including the SDP offer/answer procedure
s <xref target="RFC3264"/>, for s <xref target="RFC3264" format="default"/>, for
negotiating a WebRTC data channel are defined in <xref target="I-D.ietf- negotiating a WebRTC data channel are defined in <xref target="RFC8864"/
mmusic-data-channel-sdpneg"/>. >.
This section, and its subsections, define the SDP considerations that ar e specific to a T.140 data channel, This section, and its subsections, define the SDP considerations that ar e specific to a T.140 data channel,
identified by an SDP 'dcmap' attribute <xref target="I-D.ietf-mmusic-dat identified by the 'subprotocol' attribute parameter, with a "t140"
a-channel-sdpneg"/> with a "t140" parameter value, in the 'dcmap' attribute.
attribute parameter value.
</t> </t>
<section anchor="sec.sdp.dcmap" title="Use of dcmap Attribute"> <section anchor="sec.sdp.dcmap" numbered="true" toc="default">
<name>Use of the &apos;dcmap&apos; Attribute</name>
<t> <t>
An offerer and answerer MUST, in each offer and answer, include an SD An offerer and answerer <bcp14>MUST</bcp14>, in each offer and answer
P 'dcmap' , include an SDP 'dcmap'
attribute <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> in the attribute <xref target="RFC8864"/> in the SDP media
SDP media description ("m="&nbsp;section) <xref target="RFC4566"/> describing
description (m= section) <xref target="I-D.ietf-mmusic-rfc4566bis"/> the Stream Control Transmission Protocol (SCTP) association
describing the SCTP association <xref target="RFC4960" format="default"/> used to realize the T.140
<xref target="RFC4960"/> used to realize the T.140 data channel. data channel.
</t> </t>
<t> <t>
The offerer and answerer MUST include the subprotocol attribute parame The offerer and answerer <bcp14>MUST</bcp14> include the 'subprotocol'
ter, attribute parameter,
with a "t140" parameter value, in the 'dcmap' attribute value. with a "t140" parameter value, in the 'dcmap' attribute.
</t> </t>
<t> <t>
The offerer and answerer MAY include the priority attribute parameter The offerer and answerer <bcp14>MAY</bcp14> include the 'priority' att
and the label attribute parameter in the 'dcmap' attribute value, as ribute parameter
specified in <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>. and the 'label' attribute parameter in the 'dcmap' attribute value, as
specified in <xref target="RFC8864"/>.
</t> </t>
<t> <aside><t>
NOTE: As specified in <xref target="I-D.ietf-rtcweb-data-channel"/>, NOTE: As specified in <xref target="RFC8831"/>,
when a data channel is negotiated using the mechanism defined in <xref when a data channel is negotiated using the mechanism defined in <xref
target="I-D.ietf-rtcweb-data-protocol"/>, target="RFC8832"/>,
the label attribute parameter value has to be the same in both directi the 'label' attribute parameter value has to be the same in both direc
ons. That rule also tions. That rule also
applies to data channels negotiated using the mechanism defined in thi s document. applies to data channels negotiated using the mechanism defined in thi s document.
</t> </t></aside>
<t> <t>
The offerer and answerer MUST NOT include the max-retr or the max-time The offerer and answerer <bcp14>MUST NOT</bcp14> include the 'max-retr
attribute parameters in the 'dcmap' attribute. If either of those ' or 'max-time'
attribute parameter in the 'dcmap' attribute. If either of those
attribute parameters is received in an offer, the answerer attribute parameters is received in an offer, the answerer
MUST reject the offer. If either of those attribute parameters is rece <bcp14>MUST</bcp14> reject the offer. If either of those attribute par
ived ameters is received
in an answer the offerer MUST NOT accept the answer. Instead, the answ in an answer, the offerer <bcp14>MUST NOT</bcp14> accept the answer. I
erer nstead, the answerer
MUST take appropriate actions, e.g., by sending a new offer without a <bcp14>MUST</bcp14> take appropriate actions, e.g., by sending a new o
T.140 data channel, or by terminating the session. ffer without a
T.140 data channel or by terminating the session.
</t> </t>
<t> <t>
If the ordered attribute parameter is included in the 'dcmap' attribut e, it MUST If the 'ordered' attribute parameter is included in the 'dcmap' attrib ute, it <bcp14>MUST</bcp14>
be assigned the value 'true'. be assigned the value 'true'.
</t> </t>
<t> <t>
Below is an example of the 'dcmap' attribute for a T.140 Below is an example of the 'dcmap' attribute for a T.140
data channel with stream id=3 and without any label: data channel with stream id=3 and without any label:
</t> </t>
<t> <t>
a=dcmap:3 subprotocol="t140" a=dcmap:3 subprotocol="t140"
</t> </t>
</section> </section>
<section anchor="sec.sdp.dcsa" title="Use of dcsa Attribute"> <section anchor="sec.sdp.dcsa" numbered="true" toc="default">
<name>Use of the &apos;dcsa&apos; Attribute</name>
<t> <t>
An offerer and answerer can, in each offer and answer, include one or more An offerer and answerer can, in each offer and answer, include one or more
SDP 'dcsa' attributes <xref target="I-D.ietf-mmusic-data-channel-sdpn SDP 'dcsa' attributes <xref target="RFC8864"/>
eg"/> in the "m=" section describing the SCTP association used
in the m= section describing the SCTP association used
to realize the T.140 data channel. to realize the T.140 data channel.
</t> </t>
<t> <t>
If an offerer or answerer receives a 'dcsa' attribute that contains an If an offerer or answerer receives a 'dcsa' attribute that contains an
SDP attribute which usage has not been defined for a T.140 data channe l, SDP attribute whose usage has not been defined for a T.140 data channe l,
the offerer or answerer should ignore the 'dcsa' attribute, following the offerer or answerer should ignore the 'dcsa' attribute, following
the rules in Section 6.7 of <xref target="I-D.ietf-mmusic-data-channel -sdpneg"/>. the rules in <xref target="RFC8864" sectionFormat="of" section="6.7"/> .
</t> </t>
<section anchor="sec.sdp.dcsa.trans" title="Maximum Character Transmissi <section anchor="sec.sdp.dcsa.trans" numbered="true" toc="default">
on Rate"> <name>Maximum Character Transmission Rate</name>
<t> <t>
A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to indi A 'dcsa' attribute can contain the SDP 'fmtp' attribute, which is us
cate ed to indicate
a maximum character transmission rate <xref target="RFC4103"/>. The a maximum character transmission rate <xref target="RFC4103"
'cps' format="default"/>. The 'cps'
attribute parameter is used to indicate the maximum character transm ission rate attribute parameter is used to indicate the maximum character transm ission rate
that the endpoint that includes the attribute is able to receive, an d the value that the endpoint that includes the attribute is able to receive, an d the value
is used as a mean value in characters per second over any 10-second interval. is used as a mean value in characters per second over any 10-second interval.
</t> </t>
<t> <t>
If the 'fmtp' attribute is included, the 'format' attribute paramete If the 'fmtp' attribute is included, the 'format' attribute
r MUST be set to "t140". parameter value <bcp14>MUST</bcp14> be set to 't140'.
</t> </t>
<t> <t>
If no 'fmtp' attribute with a 'cps' attribute parameter is included, the default value of If no 'fmtp' attribute with a 'cps' attribute parameter is included, the default value of
30 applies <xref target="RFC4103"/>. 30 applies <xref target="RFC4103" format="default"/>.
</t> </t>
<t> <t>
The offerer and answerer MAY modify the 'cps' attribute parameter va lue in subsequent The offerer and answerer <bcp14>MAY</bcp14> modify the 'cps' attribu te parameter value in subsequent
offers and answers. offers and answers.
</t> </t>
<t> <t>
This document does not define any other usage of the 'fmtp' attribut e for a T.140 channel. This document does not define any other usage of the 'fmtp' attribut e for a T.140 channel.
If an offerer or answerer receives a 'dcsa' attribute that contains an 'fmtp' attribute that If an offerer or answerer receives a 'dcsa' attribute that contains an 'fmtp' attribute that
is not according to the procedure above, the offerer or answerer MUS T ignore the 'dcsa' is not set according to the procedure above, the offerer or answerer <bcp14>MUST</bcp14> ignore the 'dcsa'
attribute. attribute.
</t> </t>
<t> <aside><t>
NOTE: The 'cps' attribute parameter is especially useful when a T.14 0 data channel NOTE: The 'cps' attribute parameter is especially useful when a T.14 0 data channel
endpoint is acting as a gateway (<xref target="sec.gw"/>) and is int endpoint is acting as a gateway (<xref target="sec.gw" format="defau
erworking with lt"/>) and is interworking with
a T.140 transport mechanism that have restrictions on how many chara a T.140 transport mechanism that has restrictions on how many charac
cters can be sent ters can be sent
per second. per second.
</t> </t></aside>
<t> <t>
If an endpoint receives text at a higher rate than it can handle, e. g., because the If an endpoint receives text at a higher rate than it can handle, e. g., because the
sending endpoint does not support the 'cps' attribute parameter, it sending endpoint does not support the 'cps' attribute parameter,
SHOULD either it <bcp14>SHOULD</bcp14> either (1)&nbsp;indicate to the sending end
indicate to the sending endpoint that it is not willing to receive m point that it is not willing to receive more text, using
ore text, using the direction attributes (<xref target="sec.sdp.dcsa.dir" format="de
the direction attributes (<xref target="sec.sdp.dcsa.dir"/>), or use fault"/>) or (2)&nbsp;use a flow-control
a flow control mechanism to reduce the rate. However, in certain applications, e.g.
mechanism to reduce the rate. However, in certain applications, e.g. , emergency services,
emergency services,
it is important to regain human interaction as soon as possible, and it might it is important to regain human interaction as soon as possible, and it might
therefore be more appropriate to simply discard the received overflo w, insert a therefore be more appropriate to simply discard the received overflo w, insert a
mark for loss <xref target="T140ad1"/>, and continue to process the received text as mark for loss <xref target="T140ad1" format="default"/>, and continu e to process the received text as
soon as possible. soon as possible.
</t> </t>
<t> <aside><t>
NOTE: At the time of writing this specification, the standardized AP I for WebRTC data channels NOTE: At the time of writing this specification, the standardized AP I for WebRTC data channels
does not support flow control. Should such be available at some poin t, a receiving endpoint does not support flow control. Should such support be available at s ome point, a receiving endpoint
might use it in order to slow down the rate of text received from th e sending endpoint. might use it in order to slow down the rate of text received from th e sending endpoint.
</t> </t></aside>
</section> </section>
<section anchor="sec.sdp.dcsa.lan" title="Real-time Text Conversation La <section anchor="sec.sdp.dcsa.lan" numbered="true" toc="default">
nguages"> <name>Real-Time Text Conversation Languages</name>
<t> <t>
'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes 'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes
<xref target="RFC8373"/> to negotiate the language to be used for th e real-time <xref target="RFC8373" format="default"/> to negotiate the language to be used for the real-time
text conversation. text conversation.
</t> </t>
<t> <t>
For a T.140 data channel, the modality is "written" <xref target="RF For a T.140 data channel, the modality is "written" <xref target="RF
C8373"/>. C8373" format="default"/>.
</t> </t>
</section> </section>
<section anchor="sec.sdp.dcsa.dir" title="Real-time Text Direction"> <section anchor="sec.sdp.dcsa.dir" numbered="true" toc="default">
<name>Real-Time Text Direction</name>
<t> <t>
'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendr 'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendr
ecv' and ecv', and
'inactive' attributes <xref target="I-D.ietf-mmusic-rfc4566bis"/> to 'inactive' attributes <xref target="RFC4566"/> to negotiate the dire
negotiate the direction in ction in
which text can be transmitted in a real-time text conversation. which text can be transmitted in a real-time text conversation.
</t> </t>
<t> <aside><t>
NOTE: A WebRTC data channel is always bi-directional. The usage of t NOTE: A WebRTC data channel is always bidirectional. The usage of th
he 'dcsa' e 'dcsa'
attribute only affects the direction in which implementations are al lowed to attribute only affects the direction in which implementations are al lowed to
transmit text on a T.140 data channel. transmit text on a T.140 data channel.
</t> </t></aside>
<t> <t>
The offer/answer rules for the direction attributes are based on the rules The offer/answer rules for the direction attributes are based on the rules
for unicast streams defined in <xref target="RFC3264"/>, as describe d below. for unicast streams defined in <xref target="RFC3264" format="defaul t"/>, as described below.
Note that the rules only apply to the direction attributes. Note that the rules only apply to the direction attributes.
</t> </t>
<t> <t>
Session-level direction attributes <xref target="I-D.ietf-mmusic-rfc 4566bis"/> have no impact Session-level direction attributes <xref target="RFC4566"/> have no impact
on a T.140 data channel. on a T.140 data channel.
</t> </t>
<section anchor="sec.sdp.dcsa.dir.neg.off" title="Generating an Offer" <section anchor="sec.sdp.dcsa.dir.neg.off" numbered="true" toc="defaul
> t">
<t> <name>Generating an Offer</name>
<t>
If the offerer wishes to both send and receive text on a T.140 d ata channel, it If the offerer wishes to both send and receive text on a T.140 d ata channel, it
SHOULD mark the data channel as sendrecv with a 'sendrecv' attri bute inside a <bcp14>SHOULD</bcp14> mark the data channel as sendrecv with a ' sendrecv' attribute inside a
'dcsa' attribute. If the offerer does not explicitly mark the da ta channel, an 'dcsa' attribute. If the offerer does not explicitly mark the da ta channel, an
implicit 'sendrecv' attribute inside a 'dcsa' attribute is appli ed by default. implicit 'sendrecv' attribute inside a 'dcsa' attribute is appli ed by default.
</t> </t>
<t> <t>
If the offerer wishes to only send text on a T.140 data channel, it If the offerer wishes to only send text on a T.140 data channel, it
MUST mark the data channel as sendonly with a 'sendonly' attribu te inside a <bcp14>MUST</bcp14> mark the data channel as sendonly with a 'se ndonly' attribute inside a
'dcsa' attribute. 'dcsa' attribute.
</t> </t>
<t> <t>
If the offerer wishes to only receive text on a T.140 data chann el, it If the offerer wishes to only receive text on a T.140 data chann el, it
MUST mark the data channel as recvonly with a 'recvonly' attribu te inside a <bcp14>MUST</bcp14> mark the data channel as recvonly with a 're cvonly' attribute inside a
'dcsa' attribute. 'dcsa' attribute.
</t> </t>
<t> <t>
If the offerer wishes to neither send nor receive text on a T.14 0 data channel, it If the offerer wishes to neither send nor receive text on a T.14 0 data channel, it
MUST mark the data channel as inactive with an 'inactive' attrib ute inside a <bcp14>MUST</bcp14> mark the data channel as inactive with an 'i nactive' attribute inside a
'dcsa' attribute. 'dcsa' attribute.
</t> </t>
<t> <t>
If the offerer has marked a data channel as sendrecv (or if the offerer did not If the offerer has marked a data channel as sendrecv (or if the offerer did not
explicitly mark the data channel) or recvonly, it MUST be prepar ed to receive explicitly mark the data channel) or recvonly, it <bcp14>MUST</b cp14> be prepared to receive
T.140 data as soon as the state of the T.140 data channel allows it. T.140 data as soon as the state of the T.140 data channel allows it.
</t> </t>
</section> </section>
<section anchor="sec.sdp.dcsa.dir.neg.ans" title="Generating an Answer <section anchor="sec.sdp.dcsa.dir.neg.ans" numbered="true" toc="defaul
"> t">
<t> <name>Generating an Answer</name>
When the answerer accepts an offer, and marks the direction of t <t>
he text When the answerer accepts an offer and marks the direction of th
e text
in the corresponding answer, the direction is based on the marki ng (or the lack in the corresponding answer, the direction is based on the marki ng (or the lack
of explicit marking) in the offer. of explicit marking) in the offer.
</t> </t>
<t> <t>
If the offerer explicitly marked the data channel as sendrecv, o If the offerer either explicitly marked the data channel as send
r if the offerer did not mark recv or did not mark
the data channel, the answerer SHOULD mark the data channel as s the data channel, the answerer <bcp14>SHOULD</bcp14> mark the da
endrecv, sendonly, recvonly or inactive ta channel as sendrecv, sendonly, recvonly, or inactive
with a 'sendrecv', 'sendonly', 'recvonly' or 'inactive' attribut with a 'sendrecv', 'sendonly', 'recvonly', or 'inactive' attribu
e respectively te, respectively,
inside a 'dcsa' attribute. If the answerer does not explicitly m ark the data channel, an inside a 'dcsa' attribute. If the answerer does not explicitly m ark the data channel, an
implicit 'sendrecv' attribute inside a 'dcsa' attribute is appli ed by default. implicit 'sendrecv' attribute inside a 'dcsa' attribute is appli ed by default.
</t> </t>
<t> <t>
If the offerer marked the data channel as sendonly, the answerer If the offerer marked the data channel as sendonly, the answerer
MUST <bcp14>MUST</bcp14>
mark the data channel as recvonly or inactive with a 'recvonly' or mark the data channel as recvonly or inactive with a 'recvonly' or
'inactive' attribute respectively inside a 'dcsa' attribute. 'inactive' attribute, respectively, inside a 'dcsa' attribute.
</t> </t>
<t> <t>
If the offerer marked the data channel as recvonly, the answerer If the offerer marked the data channel as recvonly, the answerer
MUST <bcp14>MUST</bcp14>
mark the data channel as sendonly or inactive with a 'sendonly' or mark the data channel as sendonly or inactive with a 'sendonly' or
'inactive' attribute respectively inside a 'dcsa' attribute. 'inactive' attribute, respectively, inside a 'dcsa' attribute.
</t> </t>
<t> <t>
If the offerer marked the data channel as inactive, the answerer If the offerer marked the data channel as inactive, the answerer
MUST <bcp14>MUST</bcp14>
mark the data channel as inactive with an 'inactive' attribute i nside a mark the data channel as inactive with an 'inactive' attribute i nside a
'dcsa' attribute. 'dcsa' attribute.
</t> </t>
<t> <t>
If the answerer has marked a data channel as sendrecv or recvonl If the answerer has marked a data channel as sendrecv or recvonl
y, it MUST be y, it <bcp14>MUST</bcp14> be
prepared to receive data as soon as the state of the T.140 data channel allows prepared to receive data as soon as the state of the T.140 data channel allows
transmission of data. transmission of data.
</t> </t>
</section> </section>
<section anchor="sec.sdp.dcsa.dir.neg.rec" title="Offerer Receiving an <section anchor="sec.sdp.dcsa.dir.neg.rec" numbered="true" toc="defaul
Answer"> t">
<t> <name>Offerer Receiving an Answer</name>
<t>
When the offerer receives an answer to the offer and the answere r has marked a When the offerer receives an answer to the offer and the answere r has marked a
data channel as sendrecv (or the answerer did not mark the data channel) data channel as sendrecv (or the answerer did not mark the data channel)
or recvonly in the answer, the offerer can start sending T.140 d ata as soon as or recvonly in the answer, the offerer can start sending T.140 d ata as soon as
the state of the T.140 data channel allows it. If the answerer h as marked the the state of the T.140 data channel allows it. If the answerer h as marked the
data channel as inactive or sendonly, the offerer MUST NOT send data channel as inactive or sendonly, the offerer <bcp14>MUST NO
any T.140 data. T</bcp14> send any T.140 data.
</t> </t>
<t> <t>
If the answerer has not marked the direction of a T.140 data cha nnel in accordance If the answerer has not marked the direction of a T.140 data cha nnel in accordance
with the procedures above, it is RECOMMENDED that the offerer do with the procedures above, it is <bcp14>RECOMMENDED</bcp14>
es not process that that the offerer not process that scenario
as an error situation, but rather assume that the answerer might as an error situation but rather assume that the answerer might
both send and both send and
receive T.140 data on the data channel. receive T.140 data on the data channel.
</t> </t>
</section> </section>
<section anchor="sec.sdp.dcsa.dir.mod" title="Modify Text Direction"> <section anchor="sec.sdp.dcsa.dir.mod" numbered="true" toc="default">
<name>Modifying the Text Direction</name>
<t> <t>
If an endpoint wishes to modify a previously negotiated text direc tion If an endpoint wishes to modify a previously negotiated text direc tion
in an ongoing session, it MUST initiate an offer that indicates th in an ongoing session, it <bcp14>MUST</bcp14> initiate an offer th
e new at indicates the new
direction, following the rules in <xref target="sec.sdp.dcsa.dir.n direction, following the rules in <xref target="sec.sdp.dcsa.dir.n
eg.off"/>. eg.off" format="default"/>.
If the answerer accepts the offer it follows the procedures in If the answerer accepts the offer, it follows the procedures in
<xref target="sec.sdp.dcsa.dir.neg.ans"/>. <xref target="sec.sdp.dcsa.dir.neg.ans" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec.sdp.ex" title="Examples"> <section anchor="sec.sdp.ex" numbered="true" toc="default">
<t> <name>Examples</name>
Below is an example of an m= section of an offer <t>
Below is an example of an "m=" section of an offer
for a T.140 data channel offering real-time text for a T.140 data channel offering real-time text
conversation in Spanish and Esperanto, and an m= section conversation in Spanish and Esperanto, and an "m=" section
in the associated answer accepting Esperanto. The maximum in the associated answer accepting Esperanto. The maximum
character transmission rate is set to 20. As the offerer and character transmission rate is set to 20. As the offerer and
answerer have not explicitly indicated the real-time text answerer have not explicitly indicated the real-time text
direction, the default direction "sendrecv" applies. direction, the default direction "sendrecv" applies.
</t> </t>
<figure> <sourcecode name="" type="sdp"><![CDATA[Offer:
<preamble></preamble>
<artwork><![CDATA[
Offer:
m=application 911 UDP/DTLS/SCTP webrtc-datachannel m=application 911 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 5000 a=sctp-port 5000
a=setup:actpass a=setup:actpass
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:t140 cps=20 a=dcsa:2 fmtp:t140 cps=20
a=dcsa:2 hlang-send:es eo a=dcsa:2 hlang-send:es eo
a=dcsa:2 hlang-recv:es eo a=dcsa:2 hlang-recv:es eo
Answer: Answer:
m=application 2004 UDP/DTLS/SCTP webrtc-datachannel m=application 2004 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 6000 a=sctp-port 6000
a=setup:passive a=setup:passive
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 fmtp:t140 cps=20 a=dcsa:2 fmtp:t140 cps=20
a=dcsa:2 hlang-send:eo a=dcsa:2 hlang-send:eo
a=dcsa:2 hlang-recv:eo a=dcsa:2 hlang-recv:eo]]></sourcecode>
<t>
]]></artwork> Below is an example of an "m=" section of an offer
</figure>
<t>
Below is an example of an m= section of an offer
for a T.140 data channel where the offerer wishes to for a T.140 data channel where the offerer wishes to
only receive real-time text, and an m= section only receive real-time text, and an "m=" section
in the associated answer indicating that the answerer in the associated answer indicating that the answerer
will only send real-time text. No maximum will only send real-time text. No maximum
character transmission rate is indicated. No preference for character transmission rate is indicated. No preference for
the language to be used for the real-time text conversation the language to be used for the real-time text conversation
is indicated. is indicated.
</t> </t>
<figure> <sourcecode name="" type="sdp"><![CDATA[Offer:
<preamble></preamble>
<artwork><![CDATA[
Offer:
m=application 1400 UDP/DTLS/SCTP webrtc-datachannel m=application 1400 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 5000 a=sctp-port 5000
a=setup:actpass a=setup:actpass
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 recvonly a=dcsa:2 recvonly
Answer: Answer:
m=application 2400 UDP/DTLS/SCTP webrtc-datachannel m=application 2400 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 6000 a=sctp-port 6000
a=setup:passive a=setup:passive
a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcmap:2 label="ACME customer service";subprotocol="t140"
a=dcsa:2 sendonly a=dcsa:2 sendonly]]></sourcecode>
]]></artwork>
</figure>
</section> </section>
</section> </section>
<section anchor="sec.t140" numbered="true" toc="default">
<section anchor="sec.t140" title="T.140 Considerations"> <name>T.140 Considerations</name>
<section anchor="sec.t140.slf" title="Session Layer Functions"> <section anchor="sec.t140.slf" numbered="true" toc="default">
<t> <name>Session-Layer Functions</name>
<t>
Section 6.1 of <xref target="T140"/> describes the generic T.140 ses sion Section 6.1 of <xref target="T140"/> describes the generic T.140 ses sion
control functions at a high-level in a signalling protocol control functions at a high level, in a manner that is independent
independent manner. The list below describes how the functions of the signaling protocol. The list below describes how the function
s
are realized when using a T.140 data channel. are realized when using a T.140 data channel.
<list style="symbols"> </t>
<t>Prepare session: An endpoint can indicate its support of T.140 <dl newline="false" spacing="normal">
data channels <dt>Prepare session:</dt>
using signalling specific means (e.g., using SIP OPTIONS <xref t <dd>An endpoint can indicate its support of T.140 data channels
arget="RFC3261"/>), or by indicating the support in an using signaling-specific means (e.g., using SIP OPTIONS <xref target="R
offer or answer (<xref target="sec.sdp"/>)</t> FC3261" format="default"/>) or by indicating the support in an
<t>Initiate session: An offer used to request the establishment of offer or answer (<xref target="sec.sdp" format="default"/>).</dd>
a <dt>Initiate session:</dt>
T.140 data channel (<xref target="sec.sdp"/>)</t> <dd>An offer is used to request the establishment of a
<t>Accept session: An answer used to accept a request to establish T.140 data channel (<xref target="sec.sdp" format="default"/>).</dd>
a <dt>Accept session:</dt>
T.140 data channel (<xref target="sec.sdp"/>)</t> <dd>An answer is used to accept a request to establish a
<t>Deny session: An answer used to reject a request to establish T.140 data channel (<xref target="sec.sdp" format="default"/>).</dd>
a T.140 data channel, using the generic procedures for rejecting <dt>Deny session:</dt>
a data channel <xref target="I-D.ietf-mmusic-data-channel-sdpneg <dd>An answer is used to reject a request to establish
"/></t> a T.140 data channel, using the generic procedures for rejecting
<t>Disconnect session: An offer or answer used to disable a previo a data channel <xref target="RFC8864"/>.</dd>
usly <dt>Disconnect session:</dt>
established T.140 data channel, using the generic procedures for <dd>An offer or answer is used to disable a previously
closing established T.140 data channel, using the generic procedures for closin
a data channel <xref target="I-D.ietf-mmusic-data-channel-sdpneg g
"/></t> a data channel <xref target="RFC8864"/>.</dd>
<t>Data: Data sent on an established T.140 data channel (<xref tar <dt>Data:</dt>
get="sec.t140.send"/>)</t> <dd>Data is sent on an established T.140 data channel (<xref target="se
</list> c.t140.send" format="default"/>).</dd>
</t> </dl>
</section> </section>
<section anchor="sec.t140.send" title="Data Encoding and Sending"> <section anchor="sec.t140.send" numbered="true" toc="default">
<t> <name>Data Encoding and Sending</name>
T.140 text is encoded and framed as T140blocks <xref target="RFC4103 <t>
"/>. T.140 text is encoded and framed as T140blocks <xref target="RFC4103
</t> " format="default"/>.
<t> </t>
Each T140block is sent on the SCTP stream <xref target="RFC4960"/> u <t>
sed to Each T140block is sent on the SCTP stream <xref target="RFC4960" for
mat="default"/> used to
realize the T.140 data channel using standard T.140 transmission pro cedures realize the T.140 data channel using standard T.140 transmission pro cedures
<xref target="T140"/>. One or more T140blocks can be sent in a singl <xref target="T140" format="default"/>. One or more T140blocks can b
e e sent in a single
SCTP user message <xref target="RFC4960"/>. Unlike RTP based transpo SCTP user message <xref target="RFC4960" format="default"/>. Unlike
rt for RTP-based transport for
real-time text <xref target="RFC4103"/>, T.140 data channels do not real-time text <xref target="RFC4103" format="default"/>, T.140 data
use redundant channels do not use redundant
transmission of text. The reason for this is that the T.140 data cha transmission of text; this is because the T.140 data channel achieve
nnel achieves s
robust transmission by using the "reliable" mode of the data channel . robust transmission by using the "reliable" mode of the data channel .
</t> </t>
<t> <t>
Data sending procedures conform to <xref target="T140"/>. Data-sending procedures conform to <xref target="T140" format="defau
</t> lt"/>.
<t> </t>
<t>
See Section 8 of <xref target="T140"/> for coding details. See Section 8 of <xref target="T140"/> for coding details.
</t> </t>
<t> <aside><t>
NOTE: The T.140 coding details contain information on optional contr ol NOTE: The T.140 coding details contain information on optional contr ol
codes for controlling the presentation which may not be supported by the codes for controlling the presentation; these control codes may not be supported by the
presentation level of the receiving application. The receiving appli cation presentation level of the receiving application. The receiving appli cation
is expected to handle reception of such T.140 control codes appropri ately is expected to handle reception of such T.140 control codes appropri ately
(e.g. ignore and skip them) even if their effect on the presentation (e.g., ignore and skip them) even if their effect on the presentatio
is not supported. n is not supported.
</t> </t></aside>
</section> </section>
<section anchor="sec.t140.buff" title="Data Buffering"> <section anchor="sec.t140.buff" numbered="true" toc="default">
<t> <name>Data Buffering</name>
As described in <xref target="T140"/>, buffering can be used to redu <t>
ce As described in <xref target="T140" format="default"/>, buffering ca
n be used to reduce
overhead, with the maximum assigned transmission interval of T140blo cks overhead, with the maximum assigned transmission interval of T140blo cks
from the buffer being 500 ms as long as there is text to send. from the buffer being 500 ms as long as there is text to send.
</t> </t>
<t> <t>
Buffering MAY also be used for staying within the maximum character Buffering <bcp14>MAY</bcp14> also be used for staying within the max
transmission rate (<xref target="sec.sdp.dcsa"/>). imum character
</t> transmission rate (<xref target="sec.sdp.dcsa" format="default"/>).
<t> </t>
<t>
An implementation needs to take the user requirements for smooth An implementation needs to take the user requirements for smooth
flow and low latency in real-time text conversation into considerati on when flow and low latency in real-time text conversation into considerati on when
assigning a transmission interval. It is RECOMMENDED to use the defa assigning a transmission interval. It is <bcp14>RECOMMENDED</bcp14>
ult transmission to use the default transmission
interval of 300 milliseconds <xref target="RFC4103"/>, for T.140 dat interval of 300 ms <xref target="RFC4103" format="default"/>, for T.
a channels. 140 data channels.
Implementers might also use lower values for specific applications r equiring low latency, Implementers might also use lower values for specific applications r equiring low latency,
taking the increased overhead in consideration. taking the increased overhead into consideration.
</t> </t>
</section> </section>
<section anchor="sec.t140.loss" title="Loss of T140blocks"> <section anchor="sec.t140.loss" numbered="true" toc="default">
<t> <name>Loss of T140blocks</name>
In case of network failure or congestion, T.140 data channels might <t>
fail and get torn down. If this happens but the session sustains, i In the case of network failure or congestion, T.140 data channels mi
t ght
is RECOMMENDED that implementations try to reestablish the T.140 fail and get torn down. If this happens but the session is sustaine
d, it
is <bcp14>RECOMMENDED</bcp14> that implementations try to reestablis
h the T.140
data channels. As a T.140 data channel does not provide a mechanism for data channels. As a T.140 data channel does not provide a mechanism for
the receiver to identify retransmitted T140blocks after channel the receiver to identify retransmitted T140blocks after channel
reestablishment, the sending endpoint MUST NOT retransmit T140blocks reestablishment, the sending endpoint <bcp14>MUST NOT</bcp14> retran
. smit T140blocks.
Similarly, a receiver SHOULD indicate to the user that there has Similarly, a receiver <bcp14>SHOULD</bcp14> indicate to the user
been a channel reestablishment, and that text might have been lost. that a channel has been reestablished and text might have been lost.
This MAY be done by inserting the missing text markers <xref target= This <bcp14>MAY</bcp14> be done by inserting the missing text marker
"T140ad1"/> s <xref target="T140ad1" format="default"/>
or in any other way evident to the user. or in any other way evident to the user.
</t> </t>
<t> <aside><t>
NOTE: If the SCTP association <xref target="RFC4960"/> used to reali NOTE: If the SCTP association <xref target="RFC4960" format="default
ze the T.140 data channel "/> used to realize the T.140 data channel
fails and gets torn down, it needs to be re-established before the T fails and gets torn down, it needs to be reestablished before the T.
.140 data channel can be 140 data channel can be
reestablished. The procedures after the reestablishment of the T.140 reestablished. After the T.140 data channel is reestablished, the
data channel defined in procedures defined in this section apply, regardless of whether only
this section apply no matter if only the T.140 data channel, or the the T.140
whole SCTP association, data channel or the whole SCTP association got torn down.
got torn down. </t></aside>
</t> </section>
</section> <section anchor="sec.t140.mul" numbered="true" toc="default">
<section anchor="sec.t140.mul" title="Multi-party Considerations"> <name>Multi-party Considerations</name>
<t> <t>
If an implementation needs to support multi-party scenarios, the imp lementation needs If an implementation needs to support multi-party scenarios, the imp lementation needs
to support multiple simultaneous T.140 data channels, one for each r emote party. At to support multiple simultaneous T.140 data channels, one for each r emote party. At
the time of writing this document, this is true even in scenarios wh ere each participant the time of writing this document, this is true even in scenarios wh ere each participant
communicates via a centralized conference server. The reason is that , unlike RTP media, communicates via a centralized conference server. This is because, u nlike RTP media,
WebRTC data channels and the T.140 protocol do not support the indic ation of the source WebRTC data channels and the T.140 protocol do not support the indic ation of the source
of T.140 data. The SDP 'dcmap' attribute label attribute parameter ( of T.140 data. The 'label' attribute parameter in the SDP 'dcmap' at
<xref target="sec.sdp.dcmap"/>) tribute (<xref target="sec.sdp.dcmap" format="default"/>)
can be used by the offerer to provide additional information about e can be used by the offerer to provide additional information about e
ach T.140 data channel, and help ach T.140 data channel and help
implementations to distinguish between them. implementations to distinguish between them.
</t> </t>
<t> <aside><t>
NOTE: Future extensions to T.140, or to the T140block, might allow i NOTE: Future extensions to T.140 or the T140block might permit the
ndicating the source indication of the source
of T.140 data, in which case it might be possible to use a single T. 140 data channel to of T.140 data, in which case it might be possible to use a single T. 140 data channel to
transport data from multiple remote sources. The usage of a single T .140 data channel, transport data from multiple remote sources. The usage of a single T .140 data channel,
without any protocol extensions, would require the conference server to only forward without any protocol extensions, would require the conference server to only forward
real-time text from one source at any given time, and e.g., include human readable text real-time text from one source at any given time and, for example, i nclude human-readable text
labels in the real-time text stream that indicate the source wheneve r the conference server labels in the real-time text stream that indicate the source wheneve r the conference server
switches the source. This would allow the receiver to present real-t ime text from different switches the source. This would allow the receiver to present real-t ime text from different
sources separately. The procedures of such mechanism are outside the sources separately. The procedures for such a mechanism are outside
scope of this document. the scope of this document.
</t> </t></aside>
</section> </section>
</section> </section>
<section anchor="sec.gw" numbered="true" toc="default">
<section anchor="sec.gw" title="Gateway Considerations"> <name>Gateway Considerations</name>
<t> <t>
A number of real-time text transports and protocols have been defined fo r A number of real-time text transports and protocols have been defined fo r
both packet-switched and circuit-switched networks. Many are based on th e both packet-switched and circuit-switched networks. Many are based on th e
ITU-T T.140 protocol on application and presentation level <xref target= "T140"/>. ITU-T T.140 protocol at the application and presentation levels <xref ta rget="T140" format="default"/>.
At the time of writing this document, some mechanisms are no longer used , as At the time of writing this document, some mechanisms are no longer used , as
the technologies they use have been obsoleted, while others are still in use. the technologies they use have been obsoleted, while others are still in use.
</t> </t>
<t> <t>
When performing interworking between T.140 data channels and real-time t ext When performing interworking between T.140 data channels and real-time t ext
in other transports and protocols, a number of factors need to be consid ered. in other transports and protocols, a number of factors need to be consid ered.
At the time of writing this document, the most common IP-based real-time text transport At the time of writing this document, the most common IP-based real-time text transport
is the RTP based mechanism defined in <xref target="RFC4103"/>. While th is the RTP-based mechanism defined in <xref target="RFC4103" format="def
is document ault"/>. While this document
does not define a complete interworking solution, this list below provid does not define a complete interworking solution, the list below provide
es some guidance s some guidance
and considerations to take into account when designing a gateway for int erworking and considerations to take into account when designing a gateway for int erworking
between T.140 data channels and RTP-based T.140 transport: between T.140 data channels and RTP-based T.140 transport:
<list style="symbols"> </t>
<t> <ul spacing="normal">
For each T.140 data channel there is an RTP stream for real-time tex <li>
t <xref target="RFC4103"/>. For each T.140 data channel, there is an RTP stream for real-time te
xt <xref target="RFC4103" format="default"/>.
Redundancy is by default declared and used on the RTP stream. There is no redundancy on the Redundancy is by default declared and used on the RTP stream. There is no redundancy on the
T.140 data channel, but the reliable property <xref target="I-D.ietf -mmusic-data-channel-sdpneg"/> T.140 data channel, but the reliable property <xref target="RFC8864" />
is set on it. is set on it.
</t> </li>
<t> <li>
During a normal text flow, T140blocks received from one network are forwarded towards the other network. During a normal text flow, T140blocks received from one network are forwarded towards the other network.
Keep-alive traffic is handled by lower layers on the T.140 data chan Keepalive traffic is handled by lower layers on the T.140 data chann
nel. A gateway might have to extract keep-alives from el. A gateway might have to extract keepalives from
incoming RTP streams, and MAY generate keep-alives on outgoing RTP s incoming RTP streams and <bcp14>MAY</bcp14> generate keepalives on o
treams. utgoing RTP streams.
</t> </li>
<t> <li>
If the gateway detects or suspects loss of data on the RTP stream, a If the gateway detects or suspects loss of data on the RTP stream an
nd the lost data has not been d the lost data has not been
retrieved using a redundancy mechanism, the gateway SHOULD insert th retrieved using a redundancy mechanism, the gateway <bcp14>SHOULD</b
e T.140 missing text cp14> insert the T.140 missing text
marker <xref target="T140ad1"/> in the data sent on the outgoing T.1 marker <xref target="T140ad1" format="default"/> in the data sent on
40 data channel. the outgoing T.140 data channel.
</t> </li>
<t> <li>
If the gateway detects that the T.140 data channel has failed and go t torn down, once the data channel has been reestablished If the gateway detects that the T.140 data channel has failed and go t torn down, once the data channel has been reestablished
the gateway SHOULD insert the T.140 missing text marker <xref target ="T140ad1"/> in the data sent on the outgoing RTP stream the gateway <bcp14>SHOULD</bcp14> insert the T.140 missing text mark er <xref target="T140ad1" format="default"/> in the data sent on the outgoing RT P stream
if it detects or suspects that data sent by the remote T.140 data ch annel endpoint was lost. if it detects or suspects that data sent by the remote T.140 data ch annel endpoint was lost.
</t> </li>
<t> <li>
If the gateway detects that the T.140 data channel has failed and go t torn down, once the data channel If the gateway detects that the T.140 data channel has failed and go t torn down, once the data channel
has been reestablished the gateway SHOULD insert the T.140 missing t ext marker <xref target="T140ad1"/> in the data has been reestablished the gateway <bcp14>SHOULD</bcp14> insert the T.140 missing text marker <xref target="T140ad1" format="default"/> in the data
sent on the outgoing T.140 data channel if it detects or suspects th at data sent or to be sent on the sent on the outgoing T.140 data channel if it detects or suspects th at data sent or to be sent on the
T.140 data channel was lost during the failure. T.140 data channel was lost during the failure.
</t> </li>
<t> <li>
The gateway MUST indicate the same text transmission direction (<xre The gateway <bcp14>MUST</bcp14> indicate the same text transmission
f target="sec.sdp.dcsa.dir"/>) on the T.140 data channel direction (<xref target="sec.sdp.dcsa.dir" format="default"/>) on the T.140 data
channel
and the RTP stream. and the RTP stream.
</t> </li>
</list> </ul>
</t> <aside><t>
<t> NOTE: In order for the gateway to insert a missing text marker or perfor
NOTE: In order for the gateway to insert a missing text marker, or to pe m other actions that require that the
rform other actions that require that the gateway have access to the T.140 data, the T.140 data cannot be
gateway has access to the T.140 data, the T.140 data cannot be encrypted encrypted end to end between the T.140 data channel endpoint
end-to-end between the T.140 data channel endpoint
and the RTP endpoint. At the time of writing this document, no mechanism to provide such end-to-end encryption is defined. and the RTP endpoint. At the time of writing this document, no mechanism to provide such end-to-end encryption is defined.
</t> </t></aside>
<aside><t>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 con
siderations.</t></aside>
</section> </section>
<section anchor="sec.8373" title="Update to RFC 8373"> <section anchor="sec.8373" numbered="true" toc="default">
<t> <name>Update to RFC 8373</name>
This document updates RFC 8373 <xref target="RFC8373"/>, by defining h <t>
ow the SDP hlang-send and hlang-recv attributes are used for This document updates <xref target="RFC8373" format="default"/> by def
ining how the SDP 'hlang-send' and 'hlang-recv' attributes are used for
the "application/webrtc-datachannel" media type. the "application/webrtc-datachannel" media type.
</t> </t>
<t> <t>
SDP offerers and answerers MUST NOT include the attributes directly in SDP offerers and answerers <bcp14>MUST NOT</bcp14> include the attribu
the m= section associated with the tes directly in the "m=" section associated with the
'application/webrtc-datachannel' media type. Instead, the attributes M "application/webrtc-datachannel" media type. Instead, the attributes <
UST be associated with bcp14>MUST</bcp14> be associated with
individual data channels, using the SDP 'dcsa' attribute. A specificat ion that defines a subprotocol individual data channels, using the SDP 'dcsa' attribute. A specificat ion that defines a subprotocol
that uses the attributes MUST specify the modality for that subprotoco l, or how to retrieve the that uses the attributes <bcp14>MUST</bcp14> specify the modality for that subprotocol, or how to retrieve the
modality if the subprotocol supports multiple modalities. The subproto col is indicated using the SDP modality if the subprotocol supports multiple modalities. The subproto col is indicated using the SDP
'dcmap' attribute. 'dcmap' attribute.
</t> </t>
</section> </section>
<section anchor="sec.sec" title="Security Considerations"> <section anchor="sec.sec" numbered="true" toc="default">
<t> <name>Security Considerations</name>
<t>
The generic WebRTC security considerations are defined in The generic WebRTC security considerations are defined in
<xref target="I-D.ietf-rtcweb-security-arch"/> and <xref target="RFC8826"/> and <xref target="RFC8827"/>.
<xref target="I-D.ietf-rtcweb-security"/>. </t>
</t> <t>
<t>
The generic security considerations for WebRTC data channels The generic security considerations for WebRTC data channels
are defined in <xref target="I-D.ietf-rtcweb-data-channel"/>. As data channels are defined in <xref target="RFC8831"/>. As data channels
are always encrypted by design, the T.140 data channels will are always encrypted by design, the T.140 data channels will
also be encrypted. also be encrypted.
</t>
<t>
The generic security considerations for the SDP-based external
negotiation method are defined in <xref target="I-D.ietf-mmusic-data-c
hannel-sdpneg"/>.
There are no additional T.140 data channel specific security considera
tions.
</t>
<t>
When performing interworking between T.140 data channels and real-time
text and
the RTP based mechanism defined in <xref target="RFC4103"/>, in order
for a gateway to
insert a missing text marker, or to perform other actions that require
that the
gateway has access to the T.140 data, the T.140 data cannot be encrypt
ed end-to-end
between the T.140 data channel endpoint and the RTP endpoint.
</t> </t>
</section>
<section anchor="sec.iana" title="IANA considerations">
<t> <t>
[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the RFC n The generic security considerations for negotiating data channels
umber of this document.] using the SDP offer/answer mechanism are defined in <xref target="RFC8
864"/>.
There are no additional security considerations specific to T.140 data
channels.
</t> </t>
<section anchor="sec.iana.sub" title="Subprotocol Identifier t140"> <t>
When performing interworking between T.140 data channels and
RTP-based T.140 transport <xref target="RFC4103" format="default"/>, i
n order for a gateway to
insert a missing text marker or perform other actions that require tha
t the
gateway have access to the T.140 data, the T.140 data cannot be
encrypted end to end
between the T.140 data channel endpoint and the RTP endpoint.
</t>
</section>
<section anchor="sec.iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="sec.iana.sub" numbered="true" toc="default">
<name>Subprotocol Identifier &quot;t140&quot;</name>
<t> <t>
This document adds the subprotocol identifier "t140" to the "WebSocket Per this document, the subprotocol identifier "t140" has been added
Subprotocol Name Registry" as follows: to the "WebSocket Subprotocol Name Registry" as follows:
</t> </t>
<texttable title="">
<ttcol align='left' width='30%'/>
<ttcol align='left'/>
<c>Subprotocol Identifier:</c>
<c>t140</c>
<c>Subprotocol Common Name:</c>
<c>ITU-T T.140 Real-Time Text</c>
<c>Subprotocol Definition:</c>
<c>RFCXXXX</c>
<c>Reference:</c> <dl newline="false" spacing="normal">
<c>RFCXXXX</c> <dt>Subprotocol Identifier:</dt>
</texttable> <dd>t140</dd>
<dt>Subprotocol Common Name:</dt>
<dd>ITU-T T.140 Real-Time Text</dd>
<dt>Subprotocol Definition:</dt>
<dd>RFC 8865</dd>
<dt>Reference:</dt>
<dd>RFC 8865</dd>
</dl>
</section> </section>
<section anchor="sec.iana.dcsa.fmtp" numbered="true" toc="default">
<section title="SDP fmtp Attribute" anchor="sec.iana.dcsa.fmtp"> <name>SDP &apos;fmtp&apos; Attribute</name>
<t> <t>
This document defines the usage of the SDP 'fmtp' attribute, if this a ttribute is This document defines the usage of the SDP 'fmtp' attribute, if this a ttribute is
included in an SDP 'dcsa' attribute and associated with an T.140 real- included in an SDP 'dcsa' attribute associated with a T.140 real-time
time text session text session
over a WebRTC data channel. The usage is defined in <xref target="sec. over a WebRTC data channel.
sdp.dcsa.trans"/>. The usage is defined in <xref target="sec.sdp.dcsa.trans" format="default"/>.
</t> </t>
<t> <t>
The usage level "dcsa(t140)" is added to the registration of the SDP ' The usage level "dcsa(t140)" has been added to the registration of the
fmtp' attribute in the Session Description SDP 'fmtp' attribute in the "Session Description
Protocol (SDP) Parameters registry as follows: Protocol (SDP) Parameters" registry as follows:
</t> </t>
<texttable title=""> <dl newline="false" spacing="normal">
<ttcol align='left' width='35%'/> <dt>Contact name:</dt>
<ttcol align='left' width='65%'/> <dd>IESG</dd>
<dt>Contact email:</dt>
<c>Contact name:</c> <dd>iesg@ietf.org</dd>
<c>IESG</c> <dt>Attribute name:</dt>
<dd>fmtp</dd>
<c>Contact email:</c> <dt>Usage level:</dt>
<c>iesg@ietf.org</c> <dd>dcsa(t140)</dd>
<dt>Purpose:</dt>
<c>Attribute name:</c> <dd>Indicate format parameters for a T.140 data channel, such as maximum
<c>fmtp</c> character transmission rates.</dd>
<dt>Reference:</dt>
<c>Usage level:</c> <dd>RFC 8865</dd>
<c>dcsa(t140)</c> </dl>
<c>Purpose:</c>
<c>
Indicate format parameters for a T.140 data channel, such as maximum
character transmission rates.
</c>
<c>Reference:</c>
<c>RFCXXXX</c>
</texttable>
</section> </section>
<section anchor="sec.iana.dcsa.hlang" numbered="true" toc="default">
<section title="SDP Language Attributes" anchor="sec.iana.dcsa.hlang"> <name>SDP Language Attributes</name>
<t> <t>
This document modifies the usage of the SDP 'hlang-send' and 'hlang-re cv' attributes, if these attributes are This document modifies the usage of the SDP 'hlang-send' and 'hlang-re cv' attributes, if these attributes are
included in SDP 'dcsa' attributes associated with an T.140 data channe included in SDP 'dcsa' attributes associated with a T.140 data channel
l. .
The modified usage is described in <xref target="sec.sdp.dcsa.lan"/>. The modified usage is described in <xref target="sec.sdp.dcsa.lan" for
mat="default"/>.
</t> </t>
<t> <t>
The usage level "dcsa(t140)" is added to the registration of the SDP ' The usage level "dcsa(t140)" has been added to the registration of the
hland-send' attribute in the Session Description SDP 'hlang-send' attribute in the "Session Description
Protocol (SDP) Parameters registry as follows: Protocol (SDP) Parameters" registry as follows:
</t> </t>
<texttable title=""> <dl newline="false" spacing="normal">
<ttcol align='left' width='35%'/> <dt>Contact name:</dt>
<ttcol align='left' width='65%'/> <dd>IESG</dd>
<dt>Contact email:</dt>
<c>Contact name:</c> <dd>iesg@ietf.org</dd>
<c>IESG</c> <dt>Attribute name:</dt>
<dd>hlang-send</dd>
<c>Contact email:</c> <dt>Usage level:</dt>
<c>iesg@ietf.org</c> <dd>dcsa(t140)</dd>
<dt>Purpose:</dt>
<c>Attribute name:</c> <dd>Negotiate the language to be used on a T.140 data channel.</dd>
<c>hlang-send</c> <dt>Reference:</dt>
<dd>RFC 8865</dd>
<c>Usage level:</c> </dl>
<c>dcsa(t140)</c>
<c>Purpose:</c>
<c>
Negotiate the language to be used on a T.140 data channel.
</c>
<c>Reference:</c>
<c>RFCXXXX</c>
</texttable>
<t> <t>
The usage level "dcsa(t140)" is added to the registration of the SDP ' The usage level "dcsa(t140)" has been added to the registration of the
hland-recv' attribute in the Session Description SDP 'hlang-recv' attribute in the "Session Description
Protocol (SDP) Parameters registry as follows: Protocol (SDP) Parameters" registry as follows:
</t> </t>
<texttable title=""> <dl newline="false" spacing="normal">
<ttcol align='left' width='35%'/> <dt>Contact name:</dt>
<ttcol align='left' width='65%'/> <dd>IESG</dd>
<dt>Contact email:</dt>
<c>Contact name:</c> <dd>iesg@ietf.org</dd>
<c>IESG</c> <dt>Attribute name:</dt>
<dd>hlang-recv</dd>
<c>Contact email:</c> <dt>Usage level:</dt>
<c>iesg@ietf.org</c> <dd>dcsa(t140)</dd>
<dt>Purpose:</dt>
<c>Attribute name:</c> <dd>Negotiate the language to be used on a T.140 data channel.</dd>
<c>hlang-recv</c> <dt>Reference:</dt>
<dd>RFC 8865</dd>
<c>Usage level:</c> </dl>
<c>dcsa(t140)</c>
<c>Purpose:</c>
<c>
Negotiate the language to be used on a T.140 data channel.
</c>
<c>Reference:</c>
<c>RFCXXXX</c>
</texttable>
</section> </section>
<section anchor="sec.iana.dcsa.direction" numbered="true" toc="default">
<section title="SDP Media Direction Attributes" anchor="sec.iana.dcsa.dire <name>SDP Media Direction Attributes</name>
ction">
<t> <t>
This document modifies the usage of the SDP 'sendonly', 'recvonly', 's This document modifies the usage of the SDP 'sendonly', 'recvonly', 's
endrecv' and 'inactive' attributes, endrecv', and 'inactive' attributes,
if these attributes are included in SDP 'dcsa' attributes associated T if these attributes are included in SDP 'dcsa' attributes associated
.140 data channel. The modified usage with a T.140 data channel. The modified usage
is described in <xref target="sec.sdp.dcsa.dir"/>. is described in <xref target="sec.sdp.dcsa.dir" format="default"/>.
</t> </t>
<t> <t>
The usage level "dcsa(t140)" is added to the registration of the SDP ' The usage level "dcsa(t140)" has been added to the registration of the
sendonly' attribute in the Session Description SDP 'sendonly' attribute in the "Session Description
Protocol (SDP) Parameters registry as follows: Protocol (SDP) Parameters" registry as follows:
</t> </t>
<texttable title=""> <dl newline="false" spacing="normal">
<ttcol align='left' width='35%'/> <dt>Contact name:</dt>
<ttcol align='left' width='65%'/> <dd>IESG</dd>
<dt>Contact email:</dt>
<c>Contact name:</c> <dd>iesg@ietf.org</dd>
<c>IESG</c> <dt>Attribute name:</dt>
<dd>sendonly</dd>
<c>Contact email:</c> <dt>Usage level:</dt>
<c>iesg@ietf.org</c> <dd>dcsa(t140)</dd>
<dt>Purpose:</dt>
<c>Attribute name:</c> <dd>Negotiate the direction in which real-time text can be sent on a
<c>sendonly</c> T.140 data channel.</dd>
<dt>Reference:</dt>
<c>Usage level:</c> <dd>RFC 8865</dd>
<c>dcsa(t140)</c> </dl>
<c>Purpose:</c>
<c>
Negotiate the direction in which real-time text can be sent on a T.1
40 data channel.
</c>
<c>Reference:</c>
<c>RFCXXXX</c>
</texttable>
<t> <t>
The usage level "dcsa(t140)" is added to the registration of the SDP ' The usage level "dcsa(t140)" has been added to the registration of the
recvonly' attribute in the Session Description SDP 'recvonly' attribute in the "Session Description
Protocol (SDP) Parameters registry as follows: Protocol (SDP) Parameters" registry as follows:
</t> </t>
<texttable title=""> <dl newline="false" spacing="normal">
<ttcol align='left' width='35%'/> <dt>Contact name:</dt>
<ttcol align='left' width='65%'/> <dd>IESG</dd>
<dt>Contact email:</dt>
<c>Contact name:</c> <dd>iesg@ietf.org</dd>
<c>IESG</c> <dt>Attribute name:</dt>
<dd>recvonly</dd>
<c>Contact email:</c> <dt>Usage level:</dt>
<c>iesg@ietf.org</c> <dd>dcsa(t140)</dd>
<dt>Purpose:</dt>
<c>Attribute name:</c> <dd>Negotiate the direction in which real-time text can be sent on
<c>recvonly</c> a T.140 data channel.</dd>
<dt>Reference:</dt>
<c>Usage level:</c> <dd>RFC 8865</dd>
<c>dcsa(t140)</c> </dl>
<c>Purpose:</c>
<c>
Negotiate the direction in which real-time text can be sent on a T.1
40 data channel.
</c>
<c>Reference:</c>
<c>RFCXXXX</c>
</texttable>
<t> <t>
The usage level "dcsa(t140)" is added to the registration of the SDP ' The usage level "dcsa(t140)" has been added to the registration of the
sendrecv' attribute in the Session Description SDP 'sendrecv' attribute in the "Session Description
Protocol (SDP) Parameters registry as follows: Protocol (SDP) Parameters" registry as follows:
</t> </t>
<texttable title=""> <dl newline="false" spacing="normal">
<ttcol align='left' width='35%'/> <dt>Contact name:</dt>
<ttcol align='left' width='65%'/> <dd>IESG</dd>
<dt>Contact email:</dt>
<dd>iesg@ietf.org</dd>
<dt>Attribute name:</dt>
<dd>sendrecv</dd>
<dt>Usage level:</dt>
<dd>dcsa(t140)</dd>
<dt>Purpose:</dt>
<dd>Negotiate the direction in which real-time text can be sent on
a T.140 data channel.</dd>
<dt>Reference:</dt>
<dd>RFC 8865</dd>
</dl>
<t>
The usage level "dcsa(t140)" has been added to the registration of the
SDP 'inactive' attribute in the "Session Description
Protocol (SDP) Parameters" registry as follows:
</t>
<dl newline="false" spacing="normal">
<dt>Contact name:</dt>
<dd>IESG</dd>
<dt>Contact email:</dt>
<dd>iesg@ietf.org</dd>
<dt>Attribute name:</dt>
<dd>inactive</dd>
<dt>Usage level:</dt>
<dd>dcsa(t140)</dd>
<dt>Purpose:</dt>
<dd>Negotiate the direction in which real-time text can be sent on
a T.140 data channel.</dd>
<dt>Reference:</dt>
<dd>RFC 8865</dd>
</dl>
</section>
</section>
</middle>
<back>
<c>Contact name:</c> <references>
<c>IESG</c> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4103.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8373.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.
xml"/>
<c>Contact email:</c> <!-- draft-ietf-rtcweb-data-channel (RFC 8831) -->
<c>iesg@ietf.org</c> <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
<front>
<title>WebRTC Data Channels</title>
<author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization/>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization/>
</author>
<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
<organization/>
</author>
<date month='September' year='2020'/>
</front>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFC8831"/>
</reference>
<c>Attribute name:</c> <!-- draft-ietf-mmusic-data-channel-sdpneg (RFC 8864) -->
<c>sendrecv</c> <reference anchor='RFC8864' target="https://www.rfc-editor.org/info/rfc8864">
<front>
<title>Negotiation Data Channels Using the Session Description
Protocol (SDP)</title>
<author initials='K' surname='Drage' fullname='Keith Drage'>
<organization />
</author>
<c>Usage level:</c> <author initials='M' surname='Makaraju' fullname='Maridi Makaraju'>
<c>dcsa(t140)</c> <organization />
</author>
<c>Purpose:</c> <author initials='R' surname='Ejzak' fullname='Richard Ejzak'>
<c> <organization />
Negotiate the direction in which real-time text can be sent on a T.1 </author>
40 data channel.
</c>
<c>Reference:</c> <author initials='J' surname='Marcon' fullname='Jerome Marcon'>
<c>RFCXXXX</c> <organization />
</texttable> </author>
<t>
The usage level "dcsa(t140)" is added to the registration of the SDP '
inactive' attribute in the Session Description
Protocol (SDP) Parameters registry as follows:
</t>
<texttable title="">
<ttcol align='left' width='35%'/>
<ttcol align='left' width='65%'/>
<c>Contact name:</c> <author initials='R' surname='Even' fullname='Roni Even'>
<c>IESG</c> <organization />
</author>
<c>Contact email:</c> <date month='September' year='2020' />
<c>iesg@ietf.org</c>
<c>Attribute name:</c> </front>
<c>inactive</c> <seriesInfo name="RFC" value="8864"/>
<seriesInfo name="DOI" value="10.17487/RFC8864"/>
<c>Usage level:</c> </reference>
<c>dcsa(t140)</c>
<c>Purpose:</c> <!--draft-ietf-rtcweb-security (RFC 8826) -->
<c> <reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
Negotiate the direction in which real-time text can be sent on a T.1 <front>
40 data channel. <title>Security Considerations for WebRTC</title>
</c> <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='September' year='2020'/>
</front>
<seriesInfo name="RFC" value="8826"/>
<seriesInfo name="DOI" value="10.17487/RFC8826"/>
</reference>
<c>Reference:</c> <!--draft-ietf-rtcweb-security-arch (RFC 8827) -->
<c>RFCXXXX</c> <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
</texttable> <front>
<title>WebRTC Security Architecture</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization/>
</author>
<date month='September' year='2020'/>
</front>
<seriesInfo name="RFC" value="8827"/>
<seriesInfo name="DOI" value="10.17487/RFC8827"/>
</reference>
</section> <reference anchor="T140" target="https://www.itu.int/rec/T-REC-T.140-199
</section> 802-I/en">
<front>
<title>Protocol for multimedia application text conversation</title>
<author>
<organization>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">
<front>
<title>Recommendation ITU-T.140 Addendum 1 (02/2000), Protocol for
multimedia application text conversation</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2000" month="February"/>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.
xml"/>
<section anchor="sec.acks" title="Acknowledgements" toc="default"> <!-- draft-ietf-rtcweb-data-protocol (RFC 8832) -->
<reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832">
<front>
<title>WebRTC Data Channel Establishment Protocol</title>
<author initials='R.' surname='Jesup' fullname='Randell Jesup'>
<organization/>
</author>
<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>
<organization/>
</author>
<author initials='M' surname='Tüxen' fullname='Michael Tüxen'>
<organization/>
</author>
<date month='September' year='2020'/>
</front>
<seriesInfo name="RFC" value="8832"/>
<seriesInfo name="DOI" value="10.17487/RFC8832"/>
</reference>
</references>
</references>
<section anchor="sec.acks" toc="default" numbered="false">
<name>Acknowledgements</name>
<t> <t>
This document is based on an earlier Internet draft edited by Keith Drag This document is based on an earlier Internet-Draft edited by <contact f
e, ullname="Keith Drage"/>,
Juergen Stoetzer-Bradler and Albrecht Schwarz. <contact fullname="Juergen Stoetzer-Bradler"/>, and <contact fullname="A
lbrecht Schwarz"/>.
</t> </t>
<t> <t>
Thomas Belling provided useful comments on the initial (pre-submission) <contact fullname="Thomas Belling"/> provided useful comments on the ini
version tial (pre&nbhy;submission) version
of the draft. Paul Kyzivat and Bernard Aboba provided comments on the dr of the current document. <contact fullname="Paul Kyzivat"/> and <contact
aft. fullname="Bernard Aboba"/> provided comments on the document.
</t> </t>
</section> </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 for
multimedia application text conversation</title>
<author><organization>ITU-T</organization></author>
<date year="1998" month="February"/>
</front>
<format type="HTML" target="https://www.itu.int/rec/T-REC-T.140-199802-I
/en"/>
</reference>
<reference anchor="T140ad1">
<front>
<title>Recommendation ITU-T.140 Addendum 1 - (02/2000), Protocol for
multimedia application text conversation</title>
<author><organization>ITU-T</organization></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>
</back> </back>
</rfc> </rfc>
 End of changes. 178 change blocks. 
809 lines changed or deleted 859 lines changed or added

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