draft-holmberg-mmusic-t140-usage-data-channel-01.txt		draft-holmberg-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) August 29, 2019		Updates: RFC8373 (if approved) September 3, 2019
	Intended status: Standards Track		Intended status: Standards Track
	Expires: March 1, 2020		Expires: March 6, 2020
	T.140 Real-time Text Conversation over WebRTC Data Channels		T.140 Real-time Text Conversation over WebRTC Data Channels
	draft-holmberg-mmusic-t140-usage-data-channel-01		draft-holmberg-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 1, 2020.		This Internet-Draft will expire on March 6, 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 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 3		3. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 3		3.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 3
	3.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 4		3.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 4
	3.2.1. Maximum Character Transmission . . . . . . . . . . . 4		3.2.1. Maximum Character Transmission . . . . . . . . . . . 4
	3.2.2. Real-time Text Conversation Languages . . . . . . . . 4		3.2.2. Real-time Text Conversation Languages . . . . . . . . 5
	3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2.3. Real-time Text Direction . . . . . . . . . . . . . . 5
	4. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 6		3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Session Layer Functions . . . . . . . . . . . . . . . . . 6		4. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 8
	4.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 6		4.1. Session Layer Functions . . . . . . . . . . . . . . . . . 8
	4.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 6		4.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 9
	4.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 7		4.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 9
	4.5. Multi-party Considerations . . . . . . . . . . . . . . . 7		4.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 9
	5. Gateway Considerations . . . . . . . . . . . . . . . . . . . 7		4.5. Multi-party Considerations . . . . . . . . . . . . . . . 10
	6. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 9		5. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 11
	8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		8.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		8.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		8.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		8.4. SDP Media Direction Attributes . . . . . . . . . . . . . 13
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
			10.1. Normative References . . . . . . . . . . . . . . . . . . 15
			10.2. Informative References . . . . . . . . . . . . . . . . . 16
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The ITU-T Protocol for multimedia application text conversation		The ITU-T Protocol for multimedia application text conversation
	(Recommendation ITU-T T.140) [T140] defines a protocol for text		(Recommendation ITU-T T.140) [T140] defines a protocol for text
	conversation, also known as real-time text. The native transport for		conversation, also known as real-time text. The native transport for
	IP networks is the "RTP Payload for Text Conversation" [RFC4103]		IP networks is the "RTP Payload for Text Conversation" [RFC4103]
	mechanism, based on the Real-time Transport Protocol (RTP) [RFC4103].		mechanism, based on the Real-time Transport Protocol (RTP) [RFC4103].
	This document specifies how a WebRTC data channel		This document specifies how a WebRTC data channel
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 34 ¶
	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.
	3.2.1. Maximum Character Transmission		3.2.1. Maximum Character Transmission
	A 'dcsa' attribute can contain the SDP fmtp attribute used to		A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to
	indicate a maximum character transmission rate [RFC4103]. The 'cps'		indicate a maximum character transmission rate [RFC4103]. The 'cps'
	attribute parameter is used indicate the maximum character		attribute parameter is used indicate the maximum character
	transmission rate that the endpoint that includes the attribute is		transmission rate that the endpoint that includes the attribute is
	able to receive. The 'format' attribute parameter is not used with		able to receive. The 'format' attribute parameter is not used with
	T.140 data channels, and MUST be set to "-".		T.140 data channels, and MUST be set to "-".
	If the fmtp attribute is not included, it indicates that no maximum		If the 'fmtp' attribute is not included, it indicates that no maximum
	character transmission rate is indicated. It does not mean that the		character transmission rate is indicated. It does not mean that the
	default value of 30 applies [RFC4103].		default value of 30 applies [RFC4103].
	The offerer and answerer MAY modify the 'cps' attribute parameter		The offerer and answerer MAY modify the 'cps' attribute parameter
	value in subsequent offers and answers.		value in subsequent offers and answers.
	NOTE: The 'cps' attribute parameter is especially useful when a T.140		NOTE: The 'cps' attribute parameter is especially useful when a T.140
	data channel endpoint is acting as a gateway [Section 5] and is		data channel endpoint is acting as a gateway [Section 5] and is
	interworking with a T.140 transport mechanism that have restrictions		interworking with a T.140 transport mechanism that have restrictions
	on how many characters can be sent per second.		on how many characters can be sent per second.
	3.2.2. Real-time Text Conversation Languages		3.2.2. Real-time Text Conversation Languages
	'dcsa' attributes can contain the SDP hlang-send and hlang-recv		'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv'
	attributes [RFC8373] to negotiate the language to be used for the		attributes [RFC8373] to negotiate the language to be used for the
	real-time text conversation.		real-time text conversation.
	For a T.140 data channel, the modality is "written" [RFC8373].		For a T.140 data channel, the modality is "written" [RFC8373].
			3.2.3. Real-time Text Direction
			'dcsa' attributes can contain the SDP 'sendonly', 'recvonly',
			'sendrecv' and 'inactive' attributes [RFC4566] to negotite the
			direction in which text can be transmitted in a real-time text
			conversation, following the procedures in [RFC3264].
			NOTE: A WebRTC data channel is always bi-directional. The usage of
			the 'dcsa' attribute only affects the direction in which
			implementations are allowed to transmit text on a T.140 data channel.
			The offer/answer rules for the direction attributes are based on the
			rules for unicast streams defined in [RFC3264], as described below.
			Note that the rules only apply to the direction attributes.
			NOTE: As for any other attribute included in a 'dcsa' attribute, the
			direction attributes only apply to the T.140 data channel for which
			the 'dcsa' attribute is used. They have no impact on other data
			channels.
			Session level direction attributes [RFC4566] have no impact on a
			T.140 data channel. An offerer and answerer MUST mark the direction
			of the text by sending a direction attribute inside aEUR~dcsa-
			attribute.
			3.2.3.1. Negotiate Text Direction
			3.2.3.1.1. Generating an Offer
			If the offerer wishes to both send or receive text on a T.140 data
			channel, it SHOULD mark the data channel as sendrecv with a
			aEUR~sendrecvaEUR[TM] attribute inside a aEUR~dcsaaEUR[TM] attribute.
			If the offerer does not explicitly mark the data channel, a
			aEUR~sendrecvaEUR[TM] attribute inside a aEUR~dcsaaEUR[TM] attribute
			is implicitly applied.
			If the offerer wishes to only send text on a T.140 data channel, it
			MUST mark the data channel as sendonly with a aEUR~sendonlyaEUR[TM]
			attribute inside a aEUR~dcsaaEUR[TM] 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
			aEUR~recvonlyaEUR[TM] attribute inside a aEUR~dcsaaEUR[TM] attribute.
			If the offerer wishes to neither send or receive text on a T.140 data
			channel, it MUST mark the data channel as inactive with a
			aEUR~inactiveaEUR[TM] attribute inside a aEUR~dcsaaEUR[TM] attribute.
			If the offerer has marked a data channel as sendrecv (implicit or
			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.
			When the offerer receives an answer to the offer, if the answerer has
			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
			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.
			3.2.3.1.2. Generating an Answer
			When the answerer accepts an offer, and marks the direction of the
			text in the corresponding answer, the marking is based on the marking
			(explicit or implicit) in the offer.
			If the offerer marked the data channel as sendrecv (implicitly or
			explicitly), the answerer MUST mark the data channel as sendrecv,
			sendonly, recvonly or inactive with a aEUR~sendrecvaEUR[TM],
			aEUR~sendonlyaEUR[TM], aEUR~recvonlyaEUR[TM] respective
			aEUR~inactiveaEUR[TM] attribute inside a aEUR~dcsaaEUR[TM] attribute.
			If the answerer does not explicitly mark the data channel, a
			aEUR~sendrecvaEUR[TM] attribute inside a aEUR~dcsaaEUR[TM] attribute
			is implicitly applied.
			If the offerer marked the data channel as sendonly, the answerer MUST
			mark the data channel as recvonly or inactive with a
			aEUR~recvonlyaEUR[TM] respective aEUR~inactiveaEUR[TM] attribute
			inside a aEUR~dcsaaEUR[TM] attribute.
			If the offerer marked the data channel as recvonly, the answerer MUST
			mark the data channel as sendonly or inactive with a
			aEUR~sendonlyaEUR[TM] respective aEUR~inactiveaEUR[TM] attribute
			inside a aEUR~dcsaaEUR[TM] attribute.
			If the offerer marked the data channel as inactive, the answerer MUST
			mark the data channel as inactive with a aEUR~inactiveaEUR[TM]
			attribute inside a aEUR~dcsaaEUR[TM] 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.
			3.2.3.2. Modify 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
			Section 3.2.3.1.1. If the answerer accepts the offer it follows the
			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,
	where the maximum character transmission rate is set to 20.		where the maximum character transmission rate is set to 20, and the
			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
	Below is an example of an m= section of an offer for a T.140 data		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		channel offering real-time text conversation in Spanish and
	Esperanto, and an m= section in the associated answer accepting		Esperanto, and an m= section in the associated answer accepting
	Esperanto.		Esperanto.
	Offer:		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
	skipping to change at page 7, line 13 ¶		skipping to change at page 9, line 35 ¶
	(Section 3.2), if such has been provided by the peer.		(Section 3.2), if such has been provided by the peer.
	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 buffer time. It is RECOMMENDED to use the default		when assigning a buffer time. It is RECOMMENDED to use the default
	transmission interval of 300 milliseconds [RFC4103], or lower, also		transmission interval of 300 milliseconds [RFC4103], or lower, also
	for T.140 data channels.		for T.140 data channels.
	4.4. Loss of T140blocks		4.4. Loss of T140blocks
	In case of network failure or congestion, T140 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 a low number of retries are made to reestablish		is RECOMMENDED that a low number of retries are made to reestablish
	the T140 data channels. If reestablishment of the T140 data channel		the T.140 data channels. If reestablishment of the T.140 data
	is successful, an implementation MUST evaluate if any T140blocks were		channel is successful, an implementation MUST evaluate if any
	lost. Retransmission of already transmitted T140blocks MUST be		T140blocks were lost. Retransmission of already transmitted
	avoided, and missing text markers [T140ad1] SHOULD be inserted in the		T140blocks MUST be avoided, and missing text markers [T140ad1] SHOULD
	received data stream where loss is detected or suspected.		be inserted in the received data stream where loss is detected or
			suspected.
	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 buffer time. It is RECOMMENDED to use the default		when assigning a buffer time. It is RECOMMENDED to use the default
	transmission interval of 300 milliseconds [RFC4103], or lower, also		transmission interval of 300 milliseconds [RFC4103], or lower, also
	for T.140 data channels.		for T.140 data channels.
	4.5. Multi-party Considerations		4.5. Multi-party Considerations
	If an implementation needs to support multi-party scenarios, the		If an implementation needs to support multi-party scenarios, the
	implementation needs to support multiple simultaneous T.140 data		implementation needs to support multiple simultaneous T.140 data
	channels, one for each remote party. At the time of writing this		channels, one for each remote party. At the time of writing this
	document, this is true even in scenarios where each participants		document, this is true even in scenarios where each participant
	communicate via a centralized conference server. The reason is that,		communicate via a centralized conference server. The reason is that,
	unlike RTP media, WebRTC data channels and the T.140 protocol do not		unlike RTP media, WebRTC data channels and the T.140 protocol do not
	support the indication of the source of T.140 data. The SDP 'dcmap'		support the indication of the source of T.140 data. The SDP 'dcmap'
	attribute label attribute parameter (Section 3.1) can be used by the		attribute label attribute parameter (Section 3.1) can be used by the
	offerer to provide additional information about each T.140 data		offerer to provide additional information about each T.140 data
	channel, and help implementations to distinguish between them.		channel, and help implementations to distinguish between them.
	NOTE: Future extensions to T.140, or to the T140block, might allow		NOTE: Future extensions to T.140, or to the T140block, might allow
	indicating the source of T.140 data, in which case it might be		indicating the source of T.140 data, in which case it might be
	possible to use a single T.140 data channel to transport data from		possible to use a single T.140 data channel to transport data from
	skipping to change at page 8, line 14 ¶		skipping to change at page 10, line 39 ¶
	are no longer used, as the technologies they use have been obsoleted		are no longer used, as the technologies they use have been obsoleted
	etc, while others are still in use.		etc, while others are still in use.
	When performing interworking between T.140 data channels and another		When performing interworking between T.140 data channels and another
	real-time text transports and protocols with real-time text in		real-time text transports and protocols with real-time text in
	another, a number of factors need to be considered. At the time of		another, a number of factors need to be considered. At the time of
	writing this document, the most common IP-based real-time text		writing this document, the most common IP-based real-time text
	transport is the RTP based mechanism defined in [RFC4103]. While		transport is the RTP based mechanism defined in [RFC4103]. While
	this document does not define a complete interworking solution, this		this document does not define a complete interworking solution, this
	list below provides some guidance and considerations to take into		list below provides some guidance and considerations to take into
	account when designing an gateway for interworking between T140 data		account when designing an gateway for interworking between T.140 data
	channels and RTP-based T.140 transport:		channels and RTP-based T.140 transport:
	o For each T.140 data channel there is an RTP stream for real-time		o For each T.140 data channel there is an RTP stream for real-time
	text [RFC4103] . Redundancy is by default declared and used on		text [RFC4103] . Redundancy is by default declared and used on
	RTP stream. On the T.140 data channel there is no redundancy, but		RTP stream. On the T.140 data channel there is no redundancy, but
	the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of		the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of
	T.140 the data channel is set.		T.140 the data channel is set.
	o During a normal text flow, T140blocks received from one network		o During a normal text flow, T140blocks received from one network
	are forwarded towards the other network. Keep-alive traffic is		are forwarded towards the other network. Keep-alive traffic is
	implicit on the T.140 data channel. A gateway might have to		implicit on the T.140 data channel. A gateway might have to
	skipping to change at page 8, line 27 ¶		skipping to change at page 11, line 4 ¶
	o For each T.140 data channel there is an RTP stream for real-time		o For each T.140 data channel there is an RTP stream for real-time
	text [RFC4103] . Redundancy is by default declared and used on		text [RFC4103] . Redundancy is by default declared and used on
	RTP stream. On the T.140 data channel there is no redundancy, but		RTP stream. On the T.140 data channel there is no redundancy, but
	the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of		the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] of
	T.140 the data channel is set.		T.140 the data channel is set.
	o During a normal text flow, T140blocks received from one network		o During a normal text flow, T140blocks received from one network
	are forwarded towards the other network. Keep-alive traffic is		are forwarded towards the other network. Keep-alive traffic is
	implicit on the T.140 data channel. A gateway might have to		implicit on the T.140 data channel. A gateway might have to
	extract keep-alives from incoming RTP streams, and MAY generate		extract keep-alives from incoming RTP streams, and MAY generate
	keep-alives on outgoing RTP streams.		keep-alives on outgoing RTP streams.
	o It is RECOMMENDED that the gateway uses the same transmission		o It is RECOMMENDED that the gateway uses the same transmission
	interval on both the T140 data channel and the RTP stream, if		interval on both the T.140 data channel and the RTP stream, if
	possible. That will reduce the delay caused by buffering.		possible. That will reduce the delay caused by buffering.
	o If the gateway detects or suspects loss of data on the RTP stream,		o If the gateway detects or suspects loss of data on the RTP stream,
	the gateway gateway SHOULD insert the T.140 missing text marker		the gateway gateway SHOULD insert the T.140 missing text marker
	[T140ad1] in the data sent on the outgoing T.140 data channel.		[T140ad1] in the data sent on the outgoing T.140 data channel.
	o If the gateway detects or suspects loss of data on the T.140 data		o If the gateway detects or suspects loss of data on the T.140 data
	channel, the gateway gateway SHOULD insert the T.140 missing text		channel, the gateway gateway SHOULD insert the T.140 missing text
	marker [T140ad1] in the data sent on the outgoing RTP stream.		marker [T140ad1] in the data sent on the outgoing RTP stream.
	o If the gateway detects that the T.140 data channel has failed and		o If the gateway detects that the T.140 data channel has failed and
	got torn down, once the data channel has been reestablished the		got torn down, once the data channel has been reestablished the
	gateway SHOULD insert the T.140 missing text marker [T140ad1] in		gateway SHOULD insert the T.140 missing text marker [T140ad1] in
	the data sent on the outgoing RTP stream.		the data sent on the outgoing RTP stream if it detects or suspects
			that data on the T.140 data channel was lost.
			o The gateway MUST indicate the same text transmission direction
			(Section 3.2.3) on the T.140 data channel and the RTP stream.
	NOTE: In order for the gateway to insert a missing text marker, or to		NOTE: In order for the gateway to insert a missing text marker, or to
	perform other actions that require that the gateway has access to the		perform other actions that require that the gateway has access to the
	T.140 data, the T.140 data cannot be encrypted end-to-end between 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. At the time of		T.140 data channel endpoint and the RTP endpoint. At the time of
	writing this document, a mechanism to provide such end-to-end		writing this document, a mechanism to provide such end-to-end
	encryption has not been defined.		encryption has not been defined.
	6. Update to RFC 8373		6. Update to RFC 8373
	skipping to change at page 9, line 35 ¶		skipping to change at page 12, line 10 ¶
	The generic security considerations for the SDP-based external		The generic security considerations for the SDP-based external
	negotiation method are defined in		negotiation method are defined in
	[I-D.ietf-mmusic-data-channel-sdpneg].		[I-D.ietf-mmusic-data-channel-sdpneg].
	8. IANA considerations		8. IANA considerations
	[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the		[RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the
	RFC number of this document.]		RFC number of this document.]
			8.1. Subprotocol Identifier t140
	This document adds the subprotocol identifier "t140" to the		This document adds the subprotocol identifier "t140" to the
	"WebSocket Subprotocol Name Registry" as follows:		"WebSocket Subprotocol Name Registry" as follows:
	+--------------------------+-------------+		+--------------------------+-------------+
	| Subprotocol Identifier: | t140 |		| Subprotocol Identifier: | t140 |
	| Subprotocol Common Name: | ITU-T T.140 |		| Subprotocol Common Name: | ITU-T T.140 |
	| Subprotocol Definition: | RFCXXXX |		| Subprotocol Definition: | RFCXXXX |
	| Reference: | RFCXXXX |		| Reference: | RFCXXXX |
	+--------------------------+-------------+		+--------------------------+-------------+
			8.2. SDP fmtp Attribute
			This document modifies the usage of the SDP 'fmtp' attribute, if this
			attribute is included in an SDP 'dcsa' attribute and associated with
			an T.140 real-time text session over a WebRTC data channel. The
			modified usage is described in Section 3.2.1.
			The usage level "dcsa(t140)" is added to the IANA registration of the
			SDP 'fmtp' attribute as follows:
			+-----------------------+-------------------------------------------+
			| Contact name: | MMUSIC Chairs |
			| Contact email: | mmusic-chairs@ietf.org |
			| Attribute name: | fmtp |
			| Usage level: | dcsa(t140) |
			| Purpose: | Indicate the maximum transmission rate |
			| | that an endpoint is willing to recive on |
			| | a T.140 data channel. |
			| Reference: | RFCXXXX |
			+-----------------------+-------------------------------------------+
			8.3. 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 an T.140 data channel. The modified usage
			is described in Section 3.2.2.
			The usage level "dcsa(t140)" is added to the IANA registration of the
			SDP 'hlang-send' attribute as follows:
			+-----------------------+-------------------------------------------+
			| Contact name: | MMUSIC Chairs |
			| Contact email: | mmusic-chairs@ietf.org |
			| Attribute name: | hlang-send |
			| Usage level: | dcsa(t140) |
			| Purpose: | Negotiate the language to be used on a |
			| | T.140 data channel. |
			| Reference: | RFCXXXX |
			+-----------------------+-------------------------------------------+
			The usage level "dcsa(t140)" is added to the IANA registration of the
			SDP 'hlang-recv' attribute as follows:
			+-----------------------+-------------------------------------------+
			| Contact name: | MMUSIC Chairs |
			| Contact email: | mmusic-chairs@ietf.org |
			| Attribute name: | hlang-recv |
			| Usage level: | dcsa(t140) |
			| Purpose: | Negotiate the language to be used on a |
			| | T.140 data channel. |
			| Reference: | RFCXXXX |
			+-----------------------+-------------------------------------------+
			8.4. 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 T.140 data channel. The
			modified usage is described in Section 3.2.3.
			The usage level "dcsa(t140)" is added to the IANA registration of the
			SDP 'sendonly' attribute as follows:
			+-----------------------+-------------------------------------------+
			| Contact name: | MMUSIC Chairs |
			| Contact email: | mmusic-chairs@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: | RFCXXXX |
			+-----------------------+-------------------------------------------+
			The usage level "dcsa(t140)" is added to the IANA registration of the
			SDP 'recvonly' attribute as follows:
			+-----------------------+-------------------------------------------+
			| Contact name: | MMUSIC Chairs |
			| Contact email: | mmusic-chairs@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: | RFCXXXX |
			+-----------------------+-------------------------------------------+
			The usage level "dcsa(t140)" is added to the IANA registration of the
			SDP 'sendrecv' attribute as follows:
			+-----------------------+-------------------------------------------+
			| Contact name: | MMUSIC Chairs |
			| Contact email: | mmusic-chairs@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: | RFCXXXX |
			+-----------------------+-------------------------------------------+
			The usage level "dcsa(t140)" is added to the IANA registration of the
			SDP 'inactive' attribute as follows:
			+-----------------------+-------------------------------------------+
			| Contact name: | MMUSIC Chairs |
			| Contact email: | mmusic-chairs@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: | RFCXXXX |
			+-----------------------+-------------------------------------------+
	9. Acknowledgements		9. Acknowledgements
	This document is based on an earlier Internet draft edited by Keith		This document is based on an earlier Internet draft edited by Keith
	Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz.		Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz.
	Thomas Belling provided useful comments on the initial (pre-		Thomas Belling provided useful comments on the initial (pre-
	submission) version of the draft. Gunnar Hellstrom provided comments		submission) version of the draft. Gunnar Hellstrom provided comments
	and text on the draft.		and text on the draft.
	10. References		10. References
End of changes. 20 change blocks.
	35 lines changed or deleted		266 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/