draft-ietf-mmusic-t140-usage-data-channel-13.txt   draft-ietf-mmusic-t140-usage-data-channel-14.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 8373 (if approved) G. Hellstrom Updates: 8373 (if approved) G. Hellstrom
Intended status: Standards TrackGunnar Hellstrom Accessible Communicatio Intended status: Standards TrackGunnar Hellstrom Accessible Communicatio
Expires: October 11, 2020 April 9, 2020 Expires: October 12, 2020 April 10, 2020
T.140 Real-time Text Conversation over WebRTC Data Channels T.140 Real-time Text Conversation over WebRTC Data Channels
draft-ietf-mmusic-t140-usage-data-channel-13 draft-ietf-mmusic-t140-usage-data-channel-14
Abstract Abstract
This document specifies how a WebRTC data channel can be used as a This document specifies how a WebRTC data channel can be used as a
transport mechanism for Real-time text using the ITU-T Protocol for transport mechanism for Real-time text using the ITU-T Protocol for
multimedia application text conversation (Recommendation ITU-T multimedia application text conversation (Recommendation ITU-T
T.140), and how the SDP offer/answer mechanism can be used to T.140), and how the SDP offer/answer mechanism can be used to
negotiate such data channel, referred to as T.140 data channel. This negotiate such data channel, referred to as T.140 data channel. This
document updates RFC 8373 to specify its use with WebRTC data document updates RFC 8373 to specify its use with WebRTC data
channels. channels.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 11, 2020. This Internet-Draft will expire on October 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 11, line 30 skipping to change at page 11, line 30
NOTE: The T.140 coding details contain information on optional NOTE: The T.140 coding details contain information on optional
control codes for controlling the presentation which may not be control codes for controlling the presentation which may not be
supported by the presentation level of the receiving application. supported by the presentation level of the receiving application.
The receiving application is expected to handle reception of such The receiving application is expected to handle reception of such
T.140 control codes appropriately (e.g. ignore and skip them) even if T.140 control codes appropriately (e.g. ignore and skip them) even if
their effect on the presentation is not supported. their effect on the presentation is not supported.
5.3. Data Buffering 5.3. Data Buffering
As described in [T140], buffering MAY be used to reduce overhead, As described in [T140], buffering can be used to reduce overhead,
with the maximum assigned transmission interval of T140blocks from with the maximum assigned transmission interval of T140blocks from
the buffer being 500 ms as long as there is text to send. the buffer being 500 ms as long as there is text to send.
Buffering can also be used for staying within the maximum character Buffering MAY also be used for staying within the maximum character
transmission rate (Section 4.2). transmission rate (Section 4.2).
An implementation needs to take the user requirements for smooth flow An implementation needs to take the user requirements for smooth flow
and low latency in real-time text conversation into consideration and low latency in real-time text conversation into consideration
when assigning a transmission interval. It is RECOMMENDED to use the when assigning a transmission interval. It is RECOMMENDED to use the
default transmission interval of 300 milliseconds [RFC4103], for default transmission interval of 300 milliseconds [RFC4103], for
T.140 data channels. Implementers might also use lower values for T.140 data channels. Implementers might also use lower values for
specific applications requiring low latency, taking the increased specific applications requiring low latency, taking the increased
overhead in consideration. overhead in consideration.
5.4. Loss of T140blocks 5.4. Loss of T140blocks
In case of network failure or congestion, T.140 data channels might In case of network failure or congestion, T.140 data channels might
fail and get torn down. If this happens but the session sustains, it fail and get torn down. If this happens but the session sustains, it
is RECOMMENDED that implementations try to reestablish the T.140 data 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 channels. As a T.140 data channel does not provide a mechanism for
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 MUST NOT retransmit T140blocks.
Similarly, a receiver SHOULD indicate to the user that there has been Similarly, a receiver SHOULD indicate to the user that there has been
a channel reestablishment, and that text might have been lost. This a channel reestablishment, and that text might have been lost. This
MAY be done by inserting the missing text markers [T140ad1] or in any MAY be done by inserting the missing text markers [T140ad1] or in any
other way evident to the user. other way evident to the user.
NOTE: If the SCTP association [RFC4960] used to realize the T.140 NOTE: If the SCTP association [RFC4960] used to realize the T.140
data channel fails and gets torn down, it needs to be re-established data channel fails and gets torn down, it needs to be re-established
before the T.140 data channel can be reestablished. The procedures before the T.140 data channel can be reestablished. The procedures
 End of changes. 6 change blocks. 
7 lines changed or deleted 7 lines changed or added

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