draft-ietf-mmusic-data-channel-sdpneg-21.txt   draft-ietf-mmusic-data-channel-sdpneg-22.txt 
MMUSIC K. Drage MMUSIC K. Drage
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track M. Makaraju Intended status: Standards Track M. Makaraju
Expires: April 20, 2019 Nokia Expires: May 23, 2019 Nokia
J. Stoetzer-Bradler J. Stoetzer-Bradler
R. Ejzak R. Ejzak
J. Marcon J. Marcon
Unaffiliated Unaffiliated
R. Even, Ed. R. Even, Ed.
Huawei Huawei
October 17, 2018 November 19, 2018
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-21 draft-ietf-mmusic-data-channel-sdpneg-22
Abstract Abstract
The Real-Time Communication in WEB-browsers (RTCWeb) working group is The Real-Time Communication in WEB-browsers (RTCWeb) working group is
charged to provide protocols to support direct interactive rich charged to provide protocols to support direct interactive rich
communications using audio, video, and data between two peers' web- communications using audio, video, and data between two peers' web-
browsers. For the support of data communication, the RTCWeb working browsers. For the support of data communication, the RTCWeb working
group has in particular defined the concept of bi-directional data group has in particular defined the concept of bi-directional data
channels over SCTP (Stream Control Transmission Protocol), where each channels over SCTP (Stream Control Transmission Protocol), where each
data channel might be used to transport other protocols, called data channel might be used to transport other protocols, called
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 20, 2019. This Internet-Draft will expire on May 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 7 skipping to change at page 4, line 7
11.16. Changes against 'draft-ejzak-mmusic-data-channel- 11.16. Changes against 'draft-ejzak-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32
11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33 11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33
11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33 11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Generic Data Channel Negotiation Aspects When Not Appendix A. Generic Data Channel Negotiation Aspects When Not
Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 Using DCEP . . . . . . . . . . . . . . . . . . . . . 36
A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 36
A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37
A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37
A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The RTCWeb working group has defined the concept of bi-directional The RTCWeb working group has defined the concept of bi-directional
data channels running on top of the Stream Control Transmission data channels running on top of the Stream Control Transmission
Protocol (SCTP) [I-D.ietf-rtcweb-data-channel]. RTCWeb allows Protocol (SCTP) [I-D.ietf-rtcweb-data-channel]. RTCWeb allows
applications to use data channels. RTCWeb defines an in-band Data applications to use data channels. RTCWeb defines an in-band Data
Channel Establishment Protocol (DCEP) Channel Establishment Protocol (DCEP)
[I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band
protocols may be used for establishing data channels. Each data protocols may be used for establishing data channels. Each data
skipping to change at page 6, line 16 skipping to change at page 6, line 16
SCTP Stream Sequence Number (SSN): the SCTP stream sequence number SCTP Stream Sequence Number (SSN): the SCTP stream sequence number
as specified in [RFC4960]. as specified in [RFC4960].
Stream identifier: The identifier of the outbound and inbound SCTP Stream identifier: The identifier of the outbound and inbound SCTP
streams composing a data channel. streams composing a data channel.
4. Applicability Statement 4. Applicability Statement
The mechanism in this document only applies to the Session The mechanism in this document only applies to the Session
Description Protocol (SDP) [RFC4566] when used together with the SDP Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used
offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of together with the SDP offer/answer mechanism [RFC3264]. Declarative
scope of this document, and is thus undefined. usage of SDP is out of scope of this document, and is thus undefined.
5. SDP Data Channel Attributes 5. SDP Data Channel Attributes
This sections defines two new SDP media-level attributes that can be This sections defines two new SDP media-level attributes that can be
used together with the SDP Offer/Answer mechanism to negotiate data used together with the SDP Offer/Answer mechanism to negotiate data
channel-specific and subprotocol-specific parameters without the channel-specific and subprotocol-specific parameters without the
usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute
provides for negotiation of channel-specific parameters. The second provides for negotiation of channel-specific parameters. The second
attribute provides for negotiation of subprotocol-specific attribute provides for negotiation of subprotocol-specific
parameters. parameters.
skipping to change at page 11, line 25 skipping to change at page 11, line 25
dcsa-value = stream-id SP attribute dcsa-value = stream-id SP attribute
attribute = <from-RFC4566> attribute = <from-RFC4566>
Example: Example:
a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP"
a=dcsa:2 accept-types:text/plain a=dcsa:2 accept-types:text/plain
Note that the reference to [RFC4566] defines where the attribute Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where
definition can be found; it does not provide any limitation on the attribute definition can be found; it does not provide any
support of attributes defined in other documents in accordance with limitation on support of attributes defined in other documents in
this attribute definition. Note however that not all SDP attributes accordance with this attribute definition. Note however that not all
are suitable as a "a=dcsa:" parameter. IANA SDP parameters contains SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP
the lists of IANA (Internet Assigned Numbers Authority) registered parameters contains the lists of IANA (Internet Assigned Numbers
session and media level or media level only SDP attributes. Authority) registered session and media level or media level only SDP
attributes.
Thus in the example above, the original attribute line "a=accept- Thus in the example above, the original attribute line "a=accept-
types:text/plain" is represented by the attribute line "a=dcsa:2 types:text/plain" is represented by the attribute line "a=dcsa:2
accept-types:text/plain", which specifies that this instance of the accept-types:text/plain", which specifies that this instance of the
MSRP subprotocol being transported on the SCTP association using the MSRP subprotocol being transported on the SCTP association using the
data channel with stream id 2 accepts plain text files. data channel with stream id 2 accepts plain text files.
As opposed to the data channel "a=dcmap:" attribute parameters, these As opposed to the data channel "a=dcmap:" attribute parameters, these
parameters are subject to offer/answer negotiation following the parameters are subject to offer/answer negotiation following the
procedures defined in the subprotocol specific documents. procedures defined in the subprotocol specific documents.
skipping to change at page 22, line 49 skipping to change at page 22, line 49
for this attribute for SCTP or SCTP/DTLS proto values". for this attribute for SCTP or SCTP/DTLS proto values".
o In the text related to "Subsequent SDP answer" in section o In the text related to "Subsequent SDP answer" in section
Section 6.7 replacement of "The DTLS/SCTP association remains open Section 6.7 replacement of "The DTLS/SCTP association remains open
..." with "The SCTP association remains open ...". ..." with "The SCTP association remains open ...".
o In the text after the second SDP answer in section Section 7 o In the text after the second SDP answer in section Section 7
replacement of "... (after SCTP/DTLS association is setup)" with replacement of "... (after SCTP/DTLS association is setup)" with
"... (after the SCTP association is set up)". "... (after the SCTP association is set up)".
o Addition of [I-D.ietf-mmusic-dtls-sdp] to the list of informative o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative
references. references.
o Addition of "a=dtls-id" attribute lines to the SDP offer/answer o Addition of "a=dtls-id" attribute lines to the SDP offer/answer
examples in Section 7. examples in Section 7.
11.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' 11.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08'
o Addition of definition of "data channel subprotocol" to Section 3 o Addition of definition of "data channel subprotocol" to Section 3
as proposed on the MMUSIC list, https://www.ietf.org/mail- as proposed on the MMUSIC list, https://www.ietf.org/mail-
archive/web/mmusic/current/msg15827.html. archive/web/mmusic/current/msg15827.html.
skipping to change at page 30, line 5 skipping to change at page 30, line 5
Replacement of this definition with "Data channel: A WebRTC data Replacement of this definition with "Data channel: A WebRTC data
channel as specified in [I-D.ietf-rtcweb-data-channel]", and channel as specified in [I-D.ietf-rtcweb-data-channel]", and
consistent usage of "data channel" in the remainder of the consistent usage of "data channel" in the remainder of the
document including the document's headline." document including the document's headline."
o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in
[I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses.
In particular we expect "webrtc-datachannel" to become a more In particular we expect "webrtc-datachannel" to become a more
general term.' general term.'
o Consistent usage of '"m" line' in whole document as per [RFC4566]. o Consistent usage of '"m" line' in whole document as per RFC4566.
o In Section 5.1 removal of the example dcmap attribute line o In Section 5.1 removal of the example dcmap attribute line
'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are
already four examples right after the ABNF rules in Section 5.1.1. already four examples right after the ABNF rules in Section 5.1.1.
Corresponding removal of following related note: "Note: This Corresponding removal of following related note: "Note: This
document does not provide a complete specification of how to document does not provide a complete specification of how to
negotiate the use of a WebRTC data channel to transport BFCP. negotiate the use of a WebRTC data channel to transport BFCP.
Procedures specific to each subprotocol such as BFCP will be Procedures specific to each subprotocol such as BFCP will be
documented elsewhere. The use of BFCP is only an example of how documented elsewhere. The use of BFCP is only an example of how
the generic procedures described herein might apply to a specific the generic procedures described herein might apply to a specific
skipping to change at page 34, line 11 skipping to change at page 34, line 11
o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa"
attributes as this is now contained in the a=sctp-port attribute, attributes as this is now contained in the a=sctp-port attribute,
and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP
association on top of the DTLS connection. association on top of the DTLS connection.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-mmusic-rfc4566bis]
Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", draft-ietf-mmusic-
rfc4566bis-30 (work in progress), July 2018.
[I-D.ietf-mmusic-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
Procedures For Stream Control Transmission Protocol (SCTP) Procedures For Stream Control Transmission Protocol (SCTP)
over Datagram Transport Layer Security (DTLS) Transport.", over Datagram Transport Layer Security (DTLS) Transport.",
draft-ietf-mmusic-sctp-sdp-26 (work in progress), April draft-ietf-mmusic-sctp-sdp-26 (work in progress), April
2017. 2017.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
skipping to change at page 34, line 44 skipping to change at page 34, line 49
[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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-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, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
skipping to change at page 35, line 25 skipping to change at page 35, line 25
[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>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-clue-datachannel] [I-D.ietf-clue-datachannel]
Holmberg, C., "CLUE Protocol data channel", draft-ietf- Holmberg, C., "CLUE Protocol data channel", draft-ietf-
clue-datachannel-15 (work in progress), August 2018. clue-datachannel-15 (work in progress), August 2018.
[I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017.
[I-D.ietf-mmusic-msrp-usage-data-channel] [I-D.ietf-mmusic-msrp-usage-data-channel]
Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
Marcon, J., and J. Recio, "MSRP over Data Channels", Marcon, J., and J. Recio, "MSRP over Data Channels",
draft-ietf-mmusic-msrp-usage-data-channel-09 (work in draft-ietf-mmusic-msrp-usage-data-channel-09 (work in
progress), May 2018. progress), May 2018.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582,
November 2006, <https://www.rfc-editor.org/info/rfc4582>. November 2006, <https://www.rfc-editor.org/info/rfc4582>.
 End of changes. 13 change blocks. 
29 lines changed or deleted 24 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/