draft-ietf-mmusic-t140-usage-data-channel-03.txt   draft-ietf-mmusic-t140-usage-data-channel-04.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: RFC8373 (if approved) September 17, 2019 Updates: RFC8373 (if approved) September 23, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: March 20, 2020 Expires: March 26, 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-03 draft-ietf-mmusic-t140-usage-data-channel-04
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 20, 2020. This Internet-Draft will expire on March 26, 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 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 3 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 3
4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4
4.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 4 4.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 4
4.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 5 4.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 5
4.2.1. Maximum Character Transmission . . . . . . . . . . . 5 4.2.1. Maximum Character Transmission . . . . . . . . . . . 5
4.2.2. Real-time Text Conversation Languages . . . . . . . . 5 4.2.2. Real-time Text Conversation Languages . . . . . . . . 6
4.2.3. Real-time Text Direction . . . . . . . . . . . . . . 5 4.2.3. Real-time Text Direction . . . . . . . . . . . . . . 6
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 9 5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 9
5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 9 5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 9
5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 10 5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 10
5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 10 5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 10
5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 10 5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 10
5.5. Multi-party Considerations . . . . . . . . . . . . . . . 11 5.5. Multi-party Considerations . . . . . . . . . . . . . . . 11
6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 11 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 11
7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 12 7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 15 skipping to change at page 4, line 15
+--------------------------+-------------------------------+ +--------------------------+-------------------------------+
| Subprotocol Identifier | t140 | | Subprotocol Identifier | t140 |
| Transmission reliability | reliable | | Transmission reliability | reliable |
| Transmission order | in-order | | Transmission order | in-order |
| Label | See Section 4.1 and Section 6 | | Label | See Section 4.1 and Section 6 |
+--------------------------+-------------------------------+ +--------------------------+-------------------------------+
4. SDP Considerations 4. SDP Considerations
The generic SDP considerations, including the SDP Offer/Answer The generic SDP considerations, including the SDP Offer/Answer
proceudres, for negotiating a WebRTC data channel are defined in procedures, for negotiating a WebRTC data channel are defined in
[I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP [I-D.ietf-mmusic-data-channel-sdpneg]. This section defines the SDP
considerations that are specific to a T.140 data channel. considerations that are specific to a T.140 data channel.
4.1. Use of dcmap Attribute 4.1. Use of dcmap Attribute
An offerer and answerer MUST, in each offer and answer, include an An offerer and answerer MUST, in each offer and answer, include an
SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the
SDP media descripton (m= section) [RFC4566] describing the SCTP SDP media descripton (m= section) [I-D.ietf-mmusic-rfc4566bis]
association [RFC4960] used to realize the T.140 data channel. describing the SCTP association [RFC4960] used to realize the T.140
data channel.
The offerer and answerer MUST include the subprotocol attribute The offerer and answerer MUST include the subprotocol attribute
parameter, with a "t140" parameter value, in the 'dcmap' attribute parameter, with a "t140" parameter value, in the 'dcmap' attribute
value. value.
The offerer and answerer MAY include the priority attribute parameter The offerer and answerer MAY include the priority attribute parameter
and the label attribute parameter in the 'dcmap' attribute value. If and the label attribute parameter in the 'dcmap' attribute value. If
the offerer includes a label attribute parameter, the answerer MUST the offerer includes a label attribute parameter, the answerer MUST
NOT change the value in the answer. NOT change the value in the answer.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
a=dcmap:3 subprotocol="t140" a=dcmap:3 subprotocol="t140"
4.2. Use of dcsa Attribute 4.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.
If an offerer or answere receives a 'dcsa' attribute that contains an
SDP attribute which usage has not been defined for a T.140 data
channel, the offerer or answerer should ignore the 'dcsa' attribute,
following the rules in [I-D.ietf-mmusic-data-channel-sdpneg].
NOTE: At the time of writing this specification, the latest verion of NOTE: At the time of writing this specification, the latest verion of
the API defined in [W3C.webrtc] does not support the use of the SDP the API defined in [W3C.webrtc] does not support the use of the SDP
attributes defined in this section. attributes defined in this section.
4.2.1. Maximum Character Transmission 4.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 to 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. 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 If the 'fmtp' attribute is included, the 'format' attribute parameter
MUST be set to "-". 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.
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 'fmtp' attribute that is not according to the
procedure above the offerer or answerer MUST discard the 'dcsa'
attribute.
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 6] and is data channel endpoint is acting as a gateway [Section 6] 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.
4.2.2. Real-time Text Conversation Languages 4.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].
4.2.3. Real-time Text Direction 4.2.3. Real-time Text Direction
'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'dcsa' attributes can contain the SDP 'sendonly', 'recvonly',
'sendrecv' and 'inactive' attributes [RFC4566] to negotite the 'sendrecv' and 'inactive' attributes [I-D.ietf-mmusic-rfc4566bis] to
direction in which text can be transmitted in a real-time text negotite the direction in which text can be transmitted in a real-
conversation. time text conversation.
NOTE: A WebRTC data channel is always bi-directional. The usage of NOTE: A WebRTC data channel is always bi-directional. The usage of
the 'dcsa' attribute only affects the direction in which the 'dcsa' attribute only affects the direction in which
implementations are allowed to transmit text on a T.140 data channel. implementations are allowed to transmit text on a T.140 data channel.
The offer/answer rules for the direction attributes are based on the The offer/answer rules for the direction attributes are based on the
rules for unicast streams defined in [RFC3264], as described below. rules for unicast streams defined in [RFC3264], as described below.
Note that the rules only apply to the direction attributes. Note that the rules only apply to the direction attributes.
Session level direction attributes [RFC4566] have no impact on a Session level direction attributes [I-D.ietf-mmusic-rfc4566bis] have
T.140 data channel. An offerer and answerer MUST mark the direction no impact on a T.140 data channel. An offerer and answerer MUST mark
of the text by sending a direction attribute inside 'dcsa' attribute. the direction of the text by sending a direction attribute inside
'dcsa' attribute.
4.2.3.1. Negotiate Text Direction 4.2.3.1. Negotiate Text Direction
4.2.3.1.1. Generating an Offer 4.2.3.1.1. Generating an Offer
If the offerer wishes to both send or receive text on a T.140 data 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 channel, it SHOULD mark the data channel as sendrecv with a
'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does
not explicitly mark the data channel, a 'sendrecv' attribute inside a not explicitly mark the data channel, a 'sendrecv' attribute inside a
'dcsa' attribute is implicitly applied. 'dcsa' attribute is implicitly applied.
skipping to change at page 7, line 47 skipping to change at page 8, line 19
4.2.3.2. Modify Text Direction 4.2.3.2. Modify Text Direction
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 4.2.3.1.1. If the answerer accepts the offer it follows the Section 4.2.3.1.1. If the answerer accepts the offer it follows the
procedures in Section 4.2.3.1.2. procedures in Section 4.2.3.1.2.
4.3. Examples 4.3. Examples
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
text transmission direction is set to "sendrecv".
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"
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. The maximum character transmission rate is set to 20, and
the default text transmission direction "sendrecv", apply.
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
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 5000 a=sctp-port 5000
a=dcmap:1 label="ACME customer service";subprotocol="t140" a=dcmap:1 label="ACME customer service";subprotocol="t140"
a=dcsa:1 fmtp:- cps=30 a=dcsa:1 fmtp:- cps=20
a=dcsa:1 hlang-send:es eo a=dcsa:1 hlang-send:es eo
a=dcsa:1 hlang-recv:es eo a=dcsa:1 hlang-recv:es eo
Answer: Answer:
m=application 911 UDP/DTLS/SCTP webrtc-datachannel m=application 911 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 5000 a=sctp-port 5000
a=dcmap:1 label="ACME customer service";subprotocol="t140" a=dcmap:1 label="ACME customer service";subprotocol="t140"
a=dcsa:1 fmtp:- cps=30 a=dcsa:1 fmtp:- cps=20
a=dcsa:1 hlang-send:eo a=dcsa:1 hlang-send:eo
a=dcsa:1 hlang-recv:eo a=dcsa:1 hlang-recv:eo
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 where the offerer wishes to only receive real-time text, and channel where the offerer wishes to only receive real-time text, and
an m= section in the associated answer indicating that the answerer an m= section in the associated answer indicating that the answerer
will only send real-time text. will only send real-time text. The default maximum character
transmission rate 30 applies. No language to be used for the real-
time text conversation is indicated.
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
a=max-message-size:1000 a=max-message-size:1000
a=sctp-port 5000 a=sctp-port 5000
a=dcmap:1 label="ACME customer service";subprotocol="t140" a=dcmap:1 label="ACME customer service";subprotocol="t140"
a=dcsa:1 recvonly a=dcsa:1 recvonly
skipping to change at page 11, line 5 skipping to change at page 10, line 46
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 a low number of retries are made to reestablish is RECOMMENDED that a low number of retries are made to reestablish
the T.140 data channels. If reestablishment of the T.140 data the T.140 data channels. If reestablishment of the T.140 data
channel is successful, an implementation MUST evaluate if any channel is successful, an implementation MUST evaluate if any
T140blocks were lost. Retransmission of already successfully T140blocks were lost. Retransmission of already successfully
transmitted T140blocks MUST be avoided, and missing text markers transmitted T140blocks MUST be avoided, and missing text markers
[T140ad1] SHOULD be inserted in the received data stream where loss [T140ad1] SHOULD be inserted in the received data stream where loss
is detected or suspected. is detected or suspected.
NOTE: If the the SCTP association [RFC4960] used to realize the T.140
data channel fails and get torn down, it needs to be re-established
before the T.140 data channel can be reestablished. The procedure
after the reestablishment of the T.140 data channel defined in this
section apply no matter if only the T.140 data channel, or the whole
SCTP association, got torn down.
5.5. Multi-party Considerations 5.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 participant 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 4.1) can be used by the attribute label attribute parameter (Section 4.1) can be used by the
skipping to change at page 16, line 7 skipping to change at page 16, line 7
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
10. Acknowledgements 10. 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. Paul Kyzivat provides comments on the draft.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc- DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
editor.org/info/rfc3264>. editor.org/info/rfc3264>.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,
<https://www.rfc-editor.org/info/rfc4103>. <https://www.rfc-editor.org/info/rfc4103>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8373] Gellens, R., "Negotiating Human Language in Real-Time [RFC8373] Gellens, R., "Negotiating Human Language in Real-Time
Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018, Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018,
<https://www.rfc-editor.org/info/rfc8373>. <https://www.rfc-editor.org/info/rfc8373>.
[I-D.ietf-mmusic-rfc4566bis]
Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", draft-ietf-mmusic-
rfc4566bis-37 (work in progress), August 2019.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015. progress), January 2015.
[I-D.ietf-mmusic-data-channel-sdpneg] [I-D.ietf-mmusic-data-channel-sdpneg]
Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R.
Even, "SDP-based Data Channel Negotiation", draft-ietf- Even, "SDP-based Data Channel Negotiation", draft-ietf-
mmusic-data-channel-sdpneg-28 (work in progress), May mmusic-data-channel-sdpneg-28 (work in progress), May
2019. 2019.
 End of changes. 22 change blocks. 
49 lines changed or deleted 52 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/