T.140 Real-Time Text Conversation over WebRTC Data ChannelsEricssonHirsalantie 1102420JorvasFinlandchrister.holmberg@ericsson.comGunnar Hellström Accessible CommunicationEsplanaden 30136 70VendelsöSwedengunnar.hellstrom@ghaccess.seSDPITU-TT.140Data ChannelWebRTCreal-time text
This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a
transport mechanism for real-time text using the ITU-T Protocol for multimedia
application text conversation (Recommendation ITU-T T.140) and
how the 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.
Status of This Memo
This is an Internet Standards Track document.
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.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() 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.
Table of Contents
. Introduction
. Conventions
. WebRTC Data Channel Considerations
. SDP Considerations
. Use of the 'dcmap' Attribute
. Use of the 'dcsa' Attribute
. Maximum Character Transmission Rate
. Real-Time Text Conversation Languages
. Real-Time Text Direction
. Examples
. T.140 Considerations
. Session-Layer Functions
. Data Encoding and Sending
. Data Buffering
. Loss of T140blocks
. Multi-party Considerations
. Gateway Considerations
. Update to RFC 8373
. Security Considerations
. IANA Considerations
. Subprotocol Identifier "t140"
. SDP 'fmtp' Attribute
. SDP Language Attributes
. SDP Media Direction Attributes
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
Introduction
The ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140)
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 , based on the Real-time Transport Protocol (RTP) .
This document specifies how a Web Real-Time Communication (WebRTC) data channel
can be used as a transport mechanism for T.140 and how the Session
Description Protocol (SDP) offer/answer mechanism
for data channels can be used to negotiate such a data channel.
In this document, a T.140 data channel refers to a WebRTC data channel for which
the instantiated subprotocol is "t140" and where the channel is negotiated
using the SDP offer/answer mechanism .
The brief notation "T.140" is used as a name for the text
conversation protocol according to .
Real-time text is intended to be entered by human users via a keyboard,
handwriting recognition, voice recognition, or any other input method.
The rate of character entry is usually at a level of a few characters
per second or less.
defines the generic data channel properties for
a T.140 data channel, and defines how they are conveyed
in an SDP 'dcmap' attribute. While this document defines how to negotiate a
T.140 data channel using the SDP offer/answer mechanism
, the generic T.140 and gateway
considerations defined in Sections , ,
and of this document can also be applied when a T.140 data channel
is established using another mechanism (e.g., the mechanism defined in
).
defines the mapping between the
SDP 'dcmap' attribute parameters and the protocol parameters used in
.
This document updates by defining how the SDP
'hlang-send' and 'hlang-recv' attributes are used for the "application/webrtc-datachannel"
media type.
ConventionsThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL",
"SHALL NOT", "SHOULD",
"SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only
when, they appear in all capitals, as shown here.WebRTC Data Channel Considerations
The following WebRTC data channel property values
apply to a T.140 data channel:
Subprotocol Identifier
t140
Transmission reliability
reliable
Transmission order
in-order
Label
See
SDP Considerations
The generic SDP considerations, including the SDP offer/answer procedures , for
negotiating a WebRTC data channel are defined in .
This section, and its subsections, define the SDP considerations that are specific to a T.140 data channel,
identified by the 'subprotocol' attribute parameter, with a "t140"
parameter value, in the 'dcmap' attribute.
Use of the 'dcmap' Attribute
An offerer and answerer MUST, in each offer and answer, include an SDP 'dcmap'
attribute in the SDP media
description ("m=" section) describing
the Stream Control Transmission Protocol (SCTP) association
used to realize the T.140
data channel.
The offerer and answerer MUST include the 'subprotocol' attribute parameter,
with a "t140" parameter value, in the 'dcmap' attribute.
The offerer and answerer MAY include the 'priority' attribute parameter
and the 'label' attribute parameter in the 'dcmap' attribute value, as
specified in .
The offerer and answerer MUST NOT include the 'max-retr' or 'max-time'
attribute parameter in the 'dcmap' attribute. If either of those
attribute parameters is received in an offer, the answerer
MUST reject the offer. If either of those attribute parameters is received
in an answer, the offerer MUST NOT accept the answer. Instead, the answerer
MUST take appropriate actions, e.g., by sending a new offer without a
T.140 data channel or by terminating the session.
If the 'ordered' attribute parameter is included in the 'dcmap' attribute, it MUST
be assigned the value 'true'.
Below is an example of the 'dcmap' attribute for a T.140
data channel with stream id=3 and without any label:
a=dcmap:3 subprotocol="t140"
Use of the 'dcsa' Attribute
An offerer and answerer can, in each offer and answer, include one or more
SDP 'dcsa' attributes
in the "m=" section describing the SCTP association used
to realize the T.140 data channel.
If an offerer or answerer receives a 'dcsa' attribute that contains an
SDP attribute 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 .
Maximum Character Transmission Rate
A 'dcsa' attribute can contain the SDP 'fmtp' attribute, which is used to indicate
a maximum character transmission rate . 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.
If the 'fmtp' attribute is included, the 'format' attribute
parameter value MUST be set to 't140'.
If no 'fmtp' attribute with a 'cps' attribute parameter is included, the default value of
30 applies .
The offerer and answerer MAY modify the 'cps' attribute parameter value in subsequent
offers and answers.
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 ignore the 'dcsa'
attribute.
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 either (1) indicate to the sending endpoint that it is not willing to receive more text, using
the direction attributes () or (2) use a flow-control
mechanism to reduce the rate. However, in certain applications, 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 , and continue to process the received text as
soon as possible.
Real-Time Text Conversation Languages
'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes
to negotiate the language to be used for the real-time
text conversation.
For a T.140 data channel, the modality is "written" .
Real-Time Text Direction
'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendrecv', and
'inactive' attributes to negotiate the direction in
which text can be transmitted in a real-time text conversation.
The offer/answer rules for the direction attributes are based on the rules
for unicast streams defined in , as described below.
Note that the rules only apply to the direction attributes.
Session-level direction attributes have no impact
on a T.140 data channel.
Generating an Offer
If the offerer wishes to both send and receive text on a T.140 data channel, it
SHOULD 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.
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' attribute inside a
'dcsa' attribute.
If the offerer wishes to only receive text on a T.140 data channel, it
MUST mark the data channel as recvonly with a 'recvonly' attribute inside a
'dcsa' attribute.
If the offerer wishes to neither send nor receive text on a T.140 data channel, it
MUST mark the data channel as inactive with an 'inactive' attribute inside a
'dcsa' attribute.
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 prepared to receive
T.140 data as soon as the state of the T.140 data channel allows it.
Generating an Answer
When the answerer accepts an 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.
If the offerer either explicitly marked the data channel as sendrecv or did not mark
the data channel, the answerer SHOULD mark the data channel as sendrecv, sendonly, recvonly, or inactive
with a 'sendrecv', 'sendonly', 'recvonly', or 'inactive' 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.
If the offerer marked the data channel as sendonly, the answerer MUST
mark the data channel as recvonly or inactive with a 'recvonly' or
'inactive' attribute, respectively, inside a 'dcsa' attribute.
If the offerer marked the data channel as recvonly, the answerer MUST
mark the data channel as sendonly or inactive with a 'sendonly' or
'inactive' attribute, respectively, inside a 'dcsa' attribute.
If the offerer marked the data channel as inactive, the answerer MUST
mark the data channel as inactive with an 'inactive' attribute inside a
'dcsa' attribute.
If the answerer has marked a data channel as sendrecv or recvonly, it MUST be
prepared to receive data as soon as the state of the T.140 data channel allows
transmission of data.
Offerer Receiving an Answer
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 send any T.140 data.
If the answerer has not marked the direction of a T.140 data channel in accordance
with the procedures above, it is RECOMMENDED
that the offerer not process that scenario
as an error situation but rather assume that the answerer might both send and
receive T.140 data on the data channel.
Modifying the Text Direction
If an endpoint wishes to modify a previously negotiated text direction
in an ongoing session, it MUST initiate an offer that indicates the new
direction, following the rules in .
If the answerer accepts the offer, it follows the procedures in
.
Examples
Below is an example of an "m=" section of an offer
for a T.140 data channel offering real-time text
conversation in Spanish and Esperanto, and an "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.
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
Below is an example of an "m=" section of an offer
for a T.140 data channel where the offerer wishes to
only receive real-time text, and an "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.
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 sendonlyT.140 ConsiderationsSession-Layer Functions
Section 6.1 of describes the generic T.140 session
control functions at a high level, in a manner that is independent
of the signaling protocol. The list below describes how the functions
are realized when using a T.140 data channel.
Prepare session:
An endpoint can indicate its support of T.140 data channels
using signaling-specific means (e.g., using SIP OPTIONS ) or by indicating the support in an
offer or answer ().
Initiate session:
An offer is used to request the establishment of a
T.140 data channel ().
Accept session:
An answer is used to accept a request to establish a
T.140 data channel ().
Deny session:
An answer is used to reject a request to establish
a T.140 data channel, using the generic procedures for rejecting
a data channel .
Disconnect session:
An offer or answer is used to disable a previously
established T.140 data channel, using the generic procedures for closing
a data channel .
Data:
Data is sent on an established T.140 data channel ().
Data Encoding and Sending
T.140 text is encoded and framed as T140blocks .
Each T140block is sent on the SCTP stream used to
realize the T.140 data channel using standard T.140 transmission procedures
. One or more T140blocks can be sent in a single
SCTP user message . Unlike RTP-based transport for
real-time text , T.140 data channels do not use redundant
transmission of text; this is because the T.140 data channel achieves
robust transmission by using the "reliable" mode of the data channel.
Data-sending procedures conform to .
See Section 8 of for coding details.
Data Buffering
As described in , 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.
Buffering MAY also be used for staying within the maximum character
transmission rate ().
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 to use the default transmission
interval of 300 ms , for T.140 data channels.
Implementers might also use lower values for specific applications requiring low latency,
taking the increased overhead into consideration.
Loss of T140blocks
In the case of network failure or congestion, T.140 data channels might
fail and get torn down. If this happens but the session is sustained, it
is RECOMMENDED 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 retransmit T140blocks.
Similarly, a receiver SHOULD indicate to the user
that a channel has been reestablished and text might have been lost.
This MAY be done by inserting the missing text markers
or in any other way evident to the user.
Multi-party Considerations
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. This is 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 ()
can be used by the offerer to provide additional information about each T.140 data channel and help
implementations to distinguish between them.
Gateway Considerations
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 at the application and presentation levels .
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.
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 mechanism defined in . While this document
does not define a complete interworking solution, 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:
For each T.140 data channel, there is an RTP stream for real-time text .
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
is set on it.
During a normal text flow, T140blocks received from one network are forwarded towards the other network.
Keepalive traffic is handled by lower layers on the T.140 data channel. A gateway might have to extract keepalives from
incoming RTP streams and MAY generate keepalives on outgoing RTP streams.
If the gateway detects or suspects loss of data on the RTP stream and the lost data has not been
retrieved using a redundancy mechanism, the gateway SHOULD insert the T.140 missing text
marker in the data sent on the outgoing T.140 data channel.
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 insert the T.140 missing text marker 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.
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 insert the T.140 missing text marker 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.
The gateway MUST indicate the same text transmission direction () on the T.140 data channel
and the RTP stream.
Update to RFC 8373
This document updates by defining how the SDP 'hlang-send' and 'hlang-recv' attributes are used for
the "application/webrtc-datachannel" media type.
SDP offerers and answerers MUST NOT include the attributes directly in the "m=" section associated with the
"application/webrtc-datachannel" media type. Instead, the attributes MUST be associated with
individual data channels, using the SDP 'dcsa' attribute. A specification that defines a subprotocol
that uses the attributes MUST 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.
Security Considerations
The generic WebRTC security considerations are defined in
and .
The generic security considerations for WebRTC data channels
are defined in . As data channels
are always encrypted by design, the T.140 data channels will
also be encrypted.
The generic security considerations for negotiating data channels
using the SDP offer/answer mechanism are defined in .
There are no additional security considerations specific to T.140 data channels.
When performing interworking between T.140 data channels and
RTP-based T.140 transport , in order for a gateway to
insert a missing text marker or perform other actions that require that 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.
IANA ConsiderationsSubprotocol Identifier "t140"
Per this document, the subprotocol identifier "t140" has been added
to the "WebSocket Subprotocol Name Registry" as follows:
Subprotocol Identifier:
t140
Subprotocol Common Name:
ITU-T T.140 Real-Time Text
Subprotocol Definition:
RFC 8865
Reference:
RFC 8865
SDP 'fmtp' Attribute
This document defines the usage of the SDP 'fmtp' attribute, if this attribute is
included in an SDP 'dcsa' attribute associated with a T.140 real-time text session
over a WebRTC data channel.
The usage is defined in .
The usage level "dcsa (t140)" has been added to the registration of the SDP 'fmtp' attribute in the "Session Description
Protocol (SDP) Parameters" registry as follows:
Contact name:
IESG
Contact email:
iesg@ietf.org
Attribute name:
fmtp
Usage level:
dcsa (t140)
Purpose:
Indicate format parameters for a T.140 data channel, such as maximum character transmission rates.
Reference:
RFC 8865
SDP Language Attributes
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 a T.140 data channel.
The modified usage is described in .
The usage level "dcsa (t140)" has been added to the registration of the SDP 'hlang-send' attribute in the "Session Description
Protocol (SDP) Parameters" registry as follows:
Contact name:
IESG
Contact email:
iesg@ietf.org
Attribute name:
hlang-send
Usage level:
dcsa (t140)
Purpose:
Negotiate the language to be used on a T.140 data channel.
Reference:
RFC 8865
The usage level "dcsa (t140)" has been added to the registration of the SDP 'hlang-recv' attribute in the "Session Description
Protocol (SDP) Parameters" registry as follows:
Contact name:
IESG
Contact email:
iesg@ietf.org
Attribute name:
hlang-recv
Usage level:
dcsa (t140)
Purpose:
Negotiate the language to be used on a T.140 data channel.
Reference:
RFC 8865
SDP Media Direction Attributes
This document modifies the usage of the SDP 'sendonly', 'recvonly', '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 .
The usage level "dcsa (t140)" has been added to the registration of the SDP 'sendonly' attribute in the "Session Description
Protocol (SDP) Parameters" registry as follows:
Contact name:
IESG
Contact email:
iesg@ietf.org
Attribute name:
sendonly
Usage level:
dcsa (t140)
Purpose:
Negotiate the direction in which real-time text can be sent on a T.140 data channel.
Reference:
RFC 8865
The usage level "dcsa (t140)" has been added to the registration of the SDP 'recvonly' attribute in the "Session Description
Protocol (SDP) Parameters" registry as follows:
Contact name:
IESG
Contact email:
iesg@ietf.org
Attribute name:
recvonly
Usage level:
dcsa (t140)
Purpose:
Negotiate the direction in which real-time text can be sent on a T.140 data channel.
Reference:
RFC 8865
The usage level "dcsa (t140)" has been added to the registration of the SDP 'sendrecv' attribute in the "Session Description
Protocol (SDP) Parameters" registry as follows:
Contact name:
IESG
Contact email:
iesg@ietf.org
Attribute name:
sendrecv
Usage level:
dcsa (t140)
Purpose:
Negotiate the direction in which real-time text can be sent on a T.140 data channel.
Reference:
RFC 8865
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:
Contact name:
IESG
Contact email:
iesg@ietf.org
Attribute name:
inactive
Usage level:
dcsa (t140)
Purpose:
Negotiate the direction in which real-time text can be sent on a T.140 data channel.
Reference:
RFC 8865
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.An Offer/Answer Model with Session Description Protocol (SDP)This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the 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 the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]RTP Payload for Text ConversationThis 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.One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.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]SDP: Session Description ProtocolThis 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]Stream Control Transmission ProtocolThis 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.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:-- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size,-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Negotiating Human Language in Real-Time CommunicationsUsers 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).This document describes the need as well as a solution that uses new SDP media attributes.Security Considerations for WebRTCWebRTC Security ArchitectureWebRTC Data ChannelsNegotiation Data Channels Using the Session Description Protocol (SDP)UnaffiliatedNokiaUnaffiliatedUnaffiliatedHuaweiProtocol for multimedia application text conversationITU-TRecommendation ITU-T T.140Recommendation ITU-T.140 Addendum 1 (02/2000), Protocol for multimedia application text conversationITU-TInformative ReferencesSIP: Session Initiation ProtocolThis 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]RTP: A Transport Protocol for Real-Time ApplicationsThis 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]WebRTC Data Channel Establishment ProtocolAcknowledgements
This document is based on an earlier Internet-Draft edited by ,
, and .
provided useful comments on the initial (pre‑submission) version
of the current document. and provided comments on the document.
Authors' AddressesEricssonHirsalantie 1102420JorvasFinlandchrister.holmberg@ericsson.comGunnar Hellström Accessible CommunicationEsplanaden 30136 70VendelsöSwedengunnar.hellstrom@ghaccess.se