draft-ietf-mmusic-t140-usage-data-channel-01.txt   draft-ietf-mmusic-t140-usage-data-channel-02.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: RFC8373 (if approved) September 10, 2019 Updates: RFC8373 (if approved) September 13, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: March 13, 2020 Expires: March 16, 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-01 draft-ietf-mmusic-t140-usage-data-channel-02
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. negotiate such data channel, referred to as T.140 data channel.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 March 13, 2020. This Internet-Draft will expire on March 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 4, line 24 skipping to change at page 4, line 24
data channels negotiated using the mechanism defined in this data channels negotiated using the mechanism defined in this
document. document.
The offerer and answerer MUST NOT include the max-retr and max-time The offerer and answerer MUST NOT include the max-retr and max-time
attribute parameters in the 'dcmap' attribute. attribute parameters in the 'dcmap' attribute.
If the ordered attribute parameter is included in the 'dcmap' If the ordered attribute parameter is included in the 'dcmap'
attribute, it MUST be assigned the value 'true'. attribute, it MUST be assigned the value 'true'.
Below is an example of the 'dcmap' attribute for a T.140 data channel Below is an example of the 'dcmap' attribute for a T.140 data channel
with stream=3 and without any label: with stream id=3 and without any label:
a=dcmap:3 subprotocol="t140" a=dcmap:3 subprotocol="t140"
3.2. Use of dcsa Attribute 3.2. Use of dcsa Attribute
An offerer and answerer MAY, in each offer and answer, include an SDP An offerer and answerer MAY, in each offer and answer, include an SDP
'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the m= 'dcsa' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the m=
section describing the SCTP association used to realize the T.140 section describing the SCTP association used to realize the T.140
data channel. data channel.
skipping to change at page 6, line 24 skipping to change at page 6, line 24
explicit) or recvonly, it MUST be prepared to receive T.140 data as explicit) or recvonly, it MUST be prepared to receive T.140 data as
soon as the state of the T.140 data channel allows it. soon as the state of the T.140 data channel allows it.
When the offerer receives an answer to the offer, if the answerer has When the offerer receives an answer to the offer, if the answerer has
marked a data channel as sendrecv (implicit or explicit) or recvonly marked a data channel as sendrecv (implicit or explicit) or recvonly
in the answer, the offerer can start to send T.140 data as soon as in the answer, the offerer can start to send T.140 data as soon as
the state of the T.140 data channel allows it. If the answerer has 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 marked the data channel as inactive or sendonly, the offerer MUST NOT
send any T.140 data. send any T.140 data.
As the answerer implementation might not support the procedures in
this section, 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 does not process that as an error
situation, but rather assume that the answerer might both send and
receive T.140 data on the data channel.
3.2.3.1.2. Generating an Answer 3.2.3.1.2. Generating an Answer
When the answerer accepts an offer, and marks the direction of the When the answerer accepts an offer, and marks the direction of the
text in the corresponding answer, the marking is based on the marking text in the corresponding answer, the marking is based on the marking
(explicit or implicit) in the offer. (explicit or implicit) in the offer.
If the offerer marked the data channel as sendrecv (implicitly or If the offerer marked the data channel as sendrecv (implicitly or
explicitly), the answerer MUST mark the data channel as sendrecv, explicitly), the answerer MUST mark the data channel as sendrecv,
sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', sendonly, recvonly or inactive with a 'sendrecv', 'sendonly',
'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute.
skipping to change at page 7, line 16 skipping to change at page 7, line 24
If an endpoint wishes to modify a previously negotiated text If an endpoint wishes to modify a previously negotiated text
direction in an ongoing session, it MUST initiate an offer that direction in an ongoing session, it MUST initiate an offer that
indicates the new direction, following the rules in indicates the new direction, following the rules in
Section 3.2.3.1.1. If the answerer accepts the offer it follows the Section 3.2.3.1.1. If the answerer accepts the offer it follows the
procedures in Section 3.2.3.1.2. procedures in Section 3.2.3.1.2.
3.3. Examples 3.3. Examples
Below is an example of an m= section describing a T.140 data channel, Below is an example of an m= section describing a T.140 data channel,
without any dcsa attributes. The default text transmission direction
"sendrecv", applies.
m=application 911 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:db8::3
a=max-message-size:1000
a=sctp-port 5000
a=dcmap:1 label="text conversation";subprotocol="t140"
Below is an example of an m= section describing a T.140 data channel,
where the maximum character transmission rate is set to 20, and the where the maximum character transmission rate is set to 20, and the
text transmission direction is set to "sendrecv". text transmission direction is set to "sendrecv".
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=dcmap:1 label="text conversation";subprotocol="t140" a=dcmap:1 label="text conversation";subprotocol="t140"
a=dcsa:1 fmtp:- cps=20 a=dcsa:1 fmtp:- cps=20
a=dcsa:1 sendrecv a=dcsa:1 sendrecv
 End of changes. 7 change blocks. 
5 lines changed or deleted 22 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/