draft-ietf-mmusic-data-channel-sdpneg-20.txt   draft-ietf-mmusic-data-channel-sdpneg-21.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: December 25, 2018 Nokia Expires: April 20, 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
June 23, 2018 October 17, 2018
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-20 draft-ietf-mmusic-data-channel-sdpneg-21
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 December 25, 2018. This Internet-Draft will expire on April 20, 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 24 skipping to change at page 4, line 24
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
channel consists of paired SCTP streams sharing the same SCTP Stream channel consists of paired SCTP streams sharing the same SCTP Stream
Identifier. Data channels are created by endpoint applications Identifier. Data channels are created by endpoint applications using
through the WebRTC API (Application Programming Interface), or other the WebRTC API (Application Programming Interface), or other prtocols
users of a data channel like CLUE [I-D.ietf-clue-datachannel] They like CLUE [I-D.ietf-clue-datachannel]. The protocols can be signaled
can be used to transport proprietary or well-defined protocols, which by the data channel "subprotocol" parameter, conceptually similar to
in the latter case can be signaled by the data channel "subprotocol" the WebSocket [RFC5234] "subprotocol". However, apart from the
parameter, conceptually similar to the WebSocket "subprotocol". "subprotocol" value transmitted to the peer, RTCWeb leaves it open
However, apart from the "subprotocol" value transmitted to the peer, how endpoint applications can agree on how to instantiate a given
RTCWeb leaves it open how endpoint applications can agree on how to subprotocol on a data channel, and whether it is signaled in-band
instantiate a given subprotocol on a data channel, and whether it is using DCEP or out-of-band using a non-DCEP protocol (or both). In
signaled in-band using DCEP or out-of-band using a non-DCEP protocol particular, the SDP offer generated by the RTCweb data channel stack
(or both). In particular, the SDP offer generated by the RTCweb data includes no channel-specific information.
channel stack includes no channel-specific information.
This document defines SDP offer/answer [RFC3264] procedures that This document defines SDP offer/answer [RFC3264] procedures that
enable out-of-band negotiation for establishing data channels for enable out-of-band negotiation for establishing data channels for
transport of well-defined subprotocols. These procedures are based transport of well-defined subprotocols. These procedures are based
on generic SDP offer/answer negotiation rules for SCTP based media on generic SDP offer/answer negotiation rules for SCTP based media
transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m"
line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP.
This document makes use of MSRP (Message Session Relay Protocol) This document makes use of MSRP (Message Session Relay Protocol)
[RFC4975] and BFCP (Binary Floor Control Protocol) [RFC4582] in many [RFC4975] and BFCP (Binary Floor Control Protocol) [RFC4582] in many
skipping to change at page 5, line 9 skipping to change at page 5, line 9
specific to each subprotocol would have to be documented elsewhere. specific to each subprotocol would have to be documented elsewhere.
For MSRP they are documented in For MSRP they are documented in
[I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some
examples is only to show how the generic procedures described herein examples is only to show how the generic procedures described herein
might apply to a specific subprotocol. might apply to a specific subprotocol.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119] [RFC8174]
3. Terminology 3. Terminology
This document uses the following terms: This document uses the following terms:
Data channel: A WebRTC data channel as specified in Data channel: A WebRTC data channel as specified in
[I-D.ietf-rtcweb-data-channel]. [I-D.ietf-rtcweb-data-channel].
Data channel stack: An entity which, upon application request, Data channel stack: An entity which, upon application request,
runs the data channel protocol to keep track of states, sending runs the data channel protocol to keep track of states, sending
skipping to change at page 5, line 34 skipping to change at page 5, line 34
Data channel properties: Fixed properties assigned to a data Data channel properties: Fixed properties assigned to a data
channel at the time of its creation. Some of these properties channel at the time of its creation. Some of these properties
determine the way the data channel stack transmits data on this determine the way the data channel stack transmits data on this
channel (e.g., stream identifier, reliability, order of channel (e.g., stream identifier, reliability, order of
delivery...). delivery...).
Data channel subprotocol: The application protocol which is Data channel subprotocol: The application protocol which is
transported over a single data channel. Data channel subprotocol transported over a single data channel. Data channel subprotocol
messages are sent as data channel payload over an established data messages are sent as data channel payload over an established data
channel. If an SDP offer/answer exchange is used as specified in channel. SDP offer/answer exchange can be used as specified in
this document to negotiate the establishment of data channels, this document to negotiate the establishment of data channels,
corresponding data channel properties, associated data channel corresponding data channel properties, associated data channel
subprotocols and data channel subprotocol properties, then the subprotocols and data channel subprotocol properties. In this
data channel subprotocols may be identified by the values of the case the data channel subprotocols may be identified by the values
"subprotocol" parameters of the SDP "a=dcmap" attribute as of the "subprotocol" parameters of the SDP "a=dcmap" attribute as
described in Section 5.1.4. Within this document the term "data described in Section 5.1.4. Within this document the term "data
channel subprotocol" is often abbreviated as just "subprotocol". channel subprotocol" is often abbreviated as just "subprotocol".
DCEP: Data Channel Establishment Protocol defined in DCEP: Data Channel Establishment Protocol defined in
[I-D.ietf-rtcweb-data-protocol]. [I-D.ietf-rtcweb-data-protocol].
In-band: Transmission through the peer-to-peer SCTP association. In-band: Transmission through the peer-to-peer SCTP association.
Out-of-band: Transmission through the application signaling path. Out-of-band: Transmission through the application signaling path.
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) [RFC4566] when used together with the SDP
offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of
scope of this document, and is thus undefined. 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.
Note: Appendix A provides information how data channels work in Note: Appendix A provides information how data channels work in
general and especially summarizes some key aspects, which should be general and especially summarizes some key aspects, which should be
considered for the negotiation of data channels if DCEP is not used. considered for the negotiation of data channels if DCEP is not used.
5.1. SDP DCMAP Attribute 5.1. SDP DCMAP Attribute
This section defines a new media level attribute "a=dcmap:" that This section defines a new media level attribute "a=dcmap:" that
defines the data channel parameters for each data channel to be defines the data channel parameters for each data channel to be
negotiated. negotiated.
The attribute is used to create, on two peers matched data channels The attribute is used to create bi-directional SCTP data channels
as pairs of oppositely directed SCTP streams having the same set of having the same set of attributes. The data channel properties
attributes. It is assumed that the data channel properties (reliable/partially reliable, ordered/unordered) need to be suitable
(reliable/partially reliable, ordered/unordered) are suitable per the per the subprotocol transport requirements.
subprotocol transport requirements.
5.1.1. DCMAP Attribute Syntax 5.1.1. DCMAP Attribute Syntax
"a=dcmap:" is a media level attribute having the following ABNF "a=dcmap:" is a media level attribute having the following ABNF
(Augmented Backus-Naur Form, [RFC5234]) syntax. (Augmented Backus-Naur Form, [RFC5234]) syntax.
Formal Syntax: Formal Syntax:
Name: dcmap Name: dcmap
skipping to change at page 7, line 19 skipping to change at page 7, line 19
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Syntax: Syntax:
dcmap-value = dcmap-stream-id dcmap-value = dcmap-stream-id
[ SP dcmap-opt *(";" dcmap-opt) ] [ SP dcmap-opt *(";" dcmap-opt) ]
dcmap-opt = ordering-opt / subprotocol-opt / label-opt dcmap-opt = ordering-opt / subprotocol-opt / label-opt
/ maxretr-opt / maxtime-opt / priority-opt / maxretr-opt / maxtime-opt / priority-opt
; Either only maxretr-opt or maxtime-opt ; Only maxretr-opt or maxtime-opt
; is present. ; is present.
dcmap-stream-id = 1*5DIGIT dcmap-stream-id = 1*5DIGIT
ordering-opt = "ordered=" ordering-value ordering-opt = "ordered=" ordering-value
ordering-value = "true" / "false" ordering-value = "true" / "false"
subprotocol-opt = "subprotocol=" quoted-string subprotocol-opt = "subprotocol=" quoted-string
label-opt = "label=" quoted-string label-opt = "label=" quoted-string
maxretr-opt = "max-retr=" maxretr-value maxretr-opt = "max-retr=" maxretr-value
maxretr-value = "0" / integer maxretr-value = "0" / integer
; number of retransmissions, ; number of retransmissions,
skipping to change at page 8, line 16 skipping to change at page 8, line 16
a=dcmap:0 a=dcmap:0
a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512 a=dcmap:1 subprotocol="BFCP";max-time=60000;priority=512
a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP" a=dcmap:2 subprotocol="MSRP";ordered=true;label="MSRP"
a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128
a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000
Note: The last example (a=dcmap:4) shows a 'label' parameter value Note: The last example (a=dcmap:4) shows a 'label' parameter value
which contains one non-printable 'escaped-char' character (the which contains one non-printable 'escaped-char' character (the
tabulator character). tabulator character).
Within an 'a=dcmap:' attribute line's 'dcmap-opt' value either only Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one
one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be
present. Both MUST NOT be present. present. Both MUST NOT be present.
5.1.2. Dcmap-stream-id Parameter 5.1.2. Dcmap-stream-id Parameter
The 'dcmap-stream-id' parameter indicates the SCTP stream identifier The 'dcmap-stream-id' parameter indicates the SCTP stream identifier
within the SCTP association used to form the data channel. within the SCTP association used to form the data channel.
5.1.3. Label Parameter 5.1.3. Label Parameter
The 'label' parameter indicates the name of the channel. It The 'label' parameter indicates the name of the channel. It
skipping to change at page 9, line 32 skipping to change at page 9, line 32
specified life-time given in milliseconds in the 'max-time' specified life-time given in milliseconds in the 'max-time'
parameter. The max-time parameter is optional. If the max-time parameter. The max-time parameter is optional. If the max-time
parameter is not present, then the generic SCTP retransmission timing parameter is not present, then the generic SCTP retransmission timing
rules apply as specified in [RFC4960]. This parameter maps to the rules apply as specified in [RFC4960]. This parameter maps to the
'Lifetime in ms' parameter defined in 'Lifetime in ms' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. [I-D.ietf-rtcweb-data-protocol].
5.1.7. Ordered Parameter 5.1.7. Ordered Parameter
The 'ordered' parameter with value "true" indicates that the receiver The 'ordered' parameter with value "true" indicates that the receiver
MUST dispatch DATA chunks in the data channel to the upper layer will dispatch DATA chunks in the data channel to the upper layer
while preserving the order. The ordered parameter is optional and while preserving the order. The ordered parameter is optional and
takes two values: "true" for ordered and "false" for unordered takes two values: "true" for ordered and "false" for unordered
delivery with "true" as the default value. Any other value is delivery with "true" as the default value. Any other value is
ignored and default "ordered=true" is assumed. In the absence of ignored and default "ordered=true" is assumed. In the absence of
this parameter "ordered=true" is assumed. This parameter maps to the this parameter "ordered=true" is assumed. This parameter maps to the
ordered or unordered data channel types as defined in ordered or unordered data channel types as defined in
[I-D.ietf-rtcweb-data-protocol]. [I-D.ietf-rtcweb-data-protocol].
5.1.8. Priority Parameter 5.1.8. Priority Parameter
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 above reference to [RFC4566] defines where the Note that the reference to [RFC4566] defines where the attribute
attribute definition can be found; it does not provide any limitation definition can be found; it does not provide any limitation on
on support of attributes defined in other documents in accordance support of attributes defined in other documents in accordance with
with this attribute definition. Note however that not all SDP this attribute definition. Note however that not all SDP attributes
attributes are suitable as a "a=dcsa:" parameter. are suitable as a "a=dcsa:" parameter. IANA SDP parameters contains
[IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned the lists of IANA (Internet Assigned Numbers Authority) registered
Numbers Authority) registered session and media level or media level session and media level or media level only SDP attributes.
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 13, line 42 skipping to change at page 13, line 42
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED
ordered=false;max-retr=<number of retransmissions> ordered=false;max-retr=<number of retransmissions>
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED DATA_CHANNEL_PARTIAL_RELIABLE_TIMED
ordered=true;max-time=<lifetime in milliseconds> ordered=true;max-time=<lifetime in milliseconds>
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
ordered=false;max-time=<lifetime in milliseconds> ordered=false;max-time=<lifetime in milliseconds>
By definition max-retr and max-time are mutually exclusive, so at By definition max-retr and max-time are mutually exclusive, so Both
most one of them MAY be present in the "a=dcmap:" attribute line. If MUST NOT be present in the "a=dcmap:" attribute line. If a SDP offer
a SDP offer contains both of these parameters then the receiver of contains both of these parameters then the receiver of such an SDP
such an SDP offer MUST reject the SDP offer. If a SDP answer offer MUST reject the SDP offer. If a SDP answer contains both of
contains both of these parameters then the offerer MUST treat the these parameters then the offerer MUST treat the associated SDP
associated SDP offer/answer failed. offer/answer failed.
6.3. Generating the Initial Offer for A Data Channel 6.3. Generating the Initial Offer for A Data Channel
When an offerer sends an initial offer, in order to negotiate an SCTP When an offerer sends an initial offer, in order to negotiate an SCTP
stream for a data channel, the offerer: stream for a data channel, the offerer:
o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2)
associated with the data channel in the "m=" section representing associated with the data channel in the "m=" section representing
the SCTP association used to realize the data channel; and the SCTP association used to realize the data channel; and
skipping to change at page 14, line 39 skipping to change at page 14, line 39
attribute SHALL be identical to the value used for the data attribute SHALL be identical to the value used for the data
channel in the offer; and channel in the offer; and
o MAY include one or more SDP dcsa attributes (Section 5.2) o MAY include one or more SDP dcsa attributes (Section 5.2)
associated with the data channel. associated with the data channel.
6.5. Offerer Processing of the SDP Answer 6.5. Offerer Processing of the SDP Answer
An offerer receiving a SDP answer performs the following: An offerer receiving a SDP answer performs the following:
o SHALL closes any created data channels as described in o SHALL close any created data channels as described in
Section 6.6.1 for which the expected "a=dcmap:" attributes are not Section 6.6.1 for which the expected "a=dcmap:" attributes are not
present in the SDP answer. If the SDP answer has no "a=dcmap" present in the SDP answer. If the SDP answer has no "a=dcmap"
attribute either the peer does not support "a=dcmap:" attributes attribute either the peer does not support "a=dcmap:" attributes
or it rejected all the data channels. In either case the offerer or it rejected all the data channels. In either case the offerer
closes all the SDP offered data channels that were open at the closes all the SDP offered data channels that were open at the
time of offer. The DTLS association and SCTP association will time of offer. The DTLS association and SCTP association will
still be setup. still be setup.
Each agent application MUST wait to send data until it has Each agent application MUST wait to send data until it has
confirmation that the data channel at the peer is instantiated. For confirmation that the data channel at the peer is instantiated. For
skipping to change at page 15, line 32 skipping to change at page 15, line 32
6.6. Modifying the Session 6.6. Modifying the Session
When an offer sends a subsequent offer, that includes information for When an offer sends a subsequent offer, that includes information for
a previously negotiated data channel, unless the offerer intends to a previously negotiated data channel, unless the offerer intends to
close the data channel (Section 6.6.1), the offerer SHALL include the close the data channel (Section 6.6.1), the offerer SHALL include the
previously negotiated SDP attributes and attribute values associated previously negotiated SDP attributes and attribute values associated
with the data channel. with the data channel.
6.6.1. Closing a Data Channel 6.6.1. Closing a Data Channel
In order to close a data channel the endpoint that wants to close In order to close a data channel, the endpoint that wants to close
SHALL send the SCTP SSN reset message [RFC6525], following the SHALL send the SCTP SSN reset message [RFC6525], following the
procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In
addition, if the closed data channel was negotiated using the offer/ addition, if the closed data channel was negotiated using the offer/
answer mechanism Section 6.3, the endpoint that closed the data answer mechanism Section 6.3, the endpoint that closed the data
channel SHALL send a subsequent offer, in which it either: channel SHALL send a subsequent offer in which it either:
o removes the SDP dcmap attribute and SDP dcsa attributes associated o removes the SDP dcmap attribute and SDP dcsa attributes associated
with the closed data channel. Once the endpoint receives a with the closed data channel. Once the endpoint receives a
successful answer, the SCTP stream identifier value can later be successful answer, the SCTP stream identifier value can later be
used for a new data channel (negotiated using DCTP or using the used for a new data channel (negotiated using DCTP or using the
offer/answer mechanism); or offer/answer mechanism); or
o immediately re-uses the SCTP stream used for the closed data o immediately re-uses the SCTP stream used for the closed data
channel for a new data channel, using the procedures in channel for a new data channel, using the procedures in
Section 6.3. The offerer SHALL use a different SDP dcmap Section 6.3. The offerer SHALL use a different SDP dcmap
skipping to change at page 17, line 5 skipping to change at page 17, line 5
c=IN IP6 IP6 2001:db8::1 c=IN IP6 IP6 2001:db8::1
a=max-message-size:100000 a=max-message-size:100000
a=sctp-port:5002 a=sctp-port:5002
a=setup:passive a=setup:passive
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
a=tls-id:dcb3ae65cddef0532d42 a=tls-id:dcb3ae65cddef0532d42
Figure 1: Example 1 Figure 1: Example 1
In the above example the SDP answerer rejected the data channel with In the example in Figure 1 the SDP answerer rejected the data channel
stream id 0 either for explicit reasons or because it does not with stream id 0 either for explicit reasons or because it does not
understand the "a=dcmap:" attribute. As a result the offerer will understand the "a=dcmap:" attribute. As a result the offerer will
close the data channel created with the SDP offer/answer negotiation close the data channel created with the SDP offer/answer negotiation
option. The SCTP association will still be setup over DTLS. At this option. The SCTP association will still be setup over DTLS. At this
point the offerer or the answerer may use DCEP negotiation to open point the offerer or the answerer may use DCEP negotiation to open
data channels. data channels.
SDP offer: SDP offer:
m=application 10001 UDP/DTLS/SCTP webrtc-datachannel m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
skipping to change at page 17, line 44 skipping to change at page 17, line 44
a=setup:passive a=setup:passive
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
a=tls-id:dcb3ae65cddef0532d42 a=tls-id:dcb3ae65cddef0532d42
a=dcmap:2 subprotocol="MSRP";label="MSRP" a=dcmap:2 subprotocol="MSRP";label="MSRP"
a=dcsa:2 accept-types:message/cpim text/plain a=dcsa:2 accept-types:message/cpim text/plain
a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc
Figure 2: Example 2 Figure 2: Example 2
In the above example the SDP offer contains data channels for BFCP In the example in Figure 2 the SDP offer contains data channels for
(Binary Floor Control Protocol) and MSRP subprotocols. The SDP BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP
answer rejected BFCP and accepted MSRP. So, the offerer closes the answer rejected BFCP and accepted MSRP. So, the offerer closes the
data channel for BFCP and both offerer and answerer may start using data channel for BFCP and both offerer and answerer may start using
the MSRP data channel (after the SCTP association is set up). The the MSRP data channel (after the SCTP association is set up). The
data channel with stream id 0 is free and can be used for future DCEP data channel with stream id 0 is free and can be used for future DCEP
or SDP offer/answer negotiation. or SDP offer/answer negotiation.
Continuing the example in Figure 2. Continuing the example in Figure 2.
Subsequent SDP offer: Subsequent SDP offer:
skipping to change at page 18, line 35 skipping to change at page 18, line 35
a=setup:passive a=setup:passive
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA
a=tls-id:dcb3ae65cddef0532d42 a=tls-id:dcb3ae65cddef0532d42
a=dcmap:4 subprotocol="MSRP";label="MSRP" a=dcmap:4 subprotocol="MSRP";label="MSRP"
a=dcsa:4 accept-types:message/cpim text/plain a=dcsa:4 accept-types:message/cpim text/plain
a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc
Figure 3: Example 3 Figure 3: Example 3
The above example is a continuation of the example in Figure 2. The The example in Figure 3 is a continuation of the example in Figure 2.
SDP offerer now removes the MSRP data channel with stream id 2, but The SDP offerer now removes the MSRP data channel with stream id 2,
opens a new MSRP data channel with stream id 4. The answerer accepts but opens a new MSRP data channel with stream id 4. The answerer
the entire offer. As a result the offerer closes the earlier accepts the entire offer. As a result the offerer closes the earlier
negotiated MSRP related data channel and both offerer and answerer negotiated MSRP related data channel and both offerer and answerer
may start using new the MSRP related data channel. may start using new the MSRP related data channel.
8. Security Considerations 8. Security Considerations
This document specifies new SDP attributes used in the negotiation of This document specifies new SDP attributes used in the negotiation of
the DATA channel parameters. the DATA channel parameters.
These parameter are negotiated as part of opening a SCTP channel over These parameter are negotiated as part of opening a SCTP channel over
DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. This document do DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. This document do
not add any security considerations to the ones specified in the not add any security considerations to the ones specified in
above document [I-D.ietf-mmusic-sctp-sdp]
Error cases like the use of unknown parameter values or violation the Error cases like the use of unknown parameter values or violation the
odd/even rule must be handled by closing the corresponding Data odd/even rule must be handled by closing the corresponding Data
Channel. Channel.
9. IANA Considerations 9. IANA Considerations
9.1. Subprotocol Identifiers 9.1. Subprotocol Identifiers
Registration of new subprotocol identifiers is performed using the Registration of new subprotocol identifiers is performed using the
existing IANA "WebSocket Subprotocol Name Registry" table. existing IANA "WebSocket Subprotocol Name Registry" table.
skipping to change at page 26, line 39 skipping to change at page 26, line 39
o In the examples in Section 7 addition of the previously missing o In the examples in Section 7 addition of the previously missing
colons to the "a=sctp-port" attribute lines. colons to the "a=sctp-port" attribute lines.
11.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 11.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02'
o Move of reference draft-ietf-rtcweb-jsep from the list of o Move of reference draft-ietf-rtcweb-jsep from the list of
normative references to the list of informative references. normative references to the list of informative references.
Remover in -07 since not referenced Remover in -07 since not referenced
o Addition of [IANA-SDP-Parameters] to the list of informative o Addition of IANA SDP parameters to the list of informative
references and addition of following two sentences to the first references and addition of following two sentences to the first
paragraph after the ABNF definition: "Note however that not all paragraph after the ABNF definition: "Note however that not all
SDP attributes are suitable as "a=dcsa:" parameter. SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP
[IANA-SDP-Parameters] contains the lists of IANA registered parameters contains the lists of IANA registered session and media
session and media level or media level only SDP attributes." level or media level only SDP attributes."
o In the introduction replacement of last sentence "This document o In the introduction replacement of last sentence "This document
defines SDP-based out-of-band negotiation procedures to establish defines SDP-based out-of-band negotiation procedures to establish
data channels for transport of well-defined subprotocols" with data channels for transport of well-defined subprotocols" with
"This document defines SDP offer/answer negotiation procedures to "This document defines SDP offer/answer negotiation procedures to
establish data channels for transport of well-defined establish data channels for transport of well-defined
subprotocols, to enable out-of-band negotiation". subprotocols, to enable out-of-band negotiation".
o Throughout the document replacement of "external negotiation" with o Throughout the document replacement of "external negotiation" with
"SDP offer/answer negotiation" and removal of term "external "SDP offer/answer negotiation" and removal of term "external
skipping to change at page 27, line 24 skipping to change at page 27, line 24
terms. terms.
o In Section 6.1 replacement of sentence "However, a single stream o In Section 6.1 replacement of sentence "However, a single stream
is managed using one method at a time." with "However, an SDP is managed using one method at a time." with "However, an SDP
offer/answer exchange MUST NOT be initiated if the associated SCTP offer/answer exchange MUST NOT be initiated if the associated SCTP
stream is already negotiated via DCEP". stream is already negotiated via DCEP".
o In Section 6.2 replacement of sentence "By definition max-retr and o In Section 6.2 replacement of sentence "By definition max-retr and
max-time are mutually exclusive, so only one of them can be max-time are mutually exclusive, so only one of them can be
present in a=dcmap" with "By definition max-retr and max-time are present in a=dcmap" with "By definition max-retr and max-time are
mutually exclusive, so at most one of them MAY be present in mutually exclusive, so aBoth MUST NOT be present in a=dcmap".
a=dcmap".
o Move of reference [WebRtcAPI] from list of normative references to o Move of reference [WebRtcAPI] from list of normative references to
list of informative references. list of informative references.
o Removal of almost all text parts, which discussed JavaScript or o Removal of almost all text parts, which discussed JavaScript or
other API specific aspects. Such API specific aspects were mainly other API specific aspects. Such API specific aspects were mainly
discussed in sub-sections of Section 5 and Section 5 of draft- discussed in sub-sections of Section 5 and Section 5 of draft-
ietf-mmusic-data-channel-sdpneg-02. ietf-mmusic-data-channel-sdpneg-02.
11.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 11.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01'
skipping to change at page 28, line 44 skipping to change at page 28, line 44
o In Section 6.7 in both bullet points related to "Subsequent SDP o In Section 6.7 in both bullet points related to "Subsequent SDP
offer" and "Subsequent SDP answer" replacement of "All the offer" and "Subsequent SDP answer" replacement of "All the
externally negotiated data channels must be closed now." with "All externally negotiated data channels must be closed now." with "All
the externally negotiated data channels are expected to be closed the externally negotiated data channels are expected to be closed
now.". now.".
o In Appendix A.2.2's sixth paragraph replacement of the two o In Appendix A.2.2's sixth paragraph replacement of the two
occurrences of "must" with "MUST". occurrences of "must" with "MUST".
o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt"
there was a comment saying that "Either only maxretr-opt or there was a comment saying that "Only maxretr-opt or maxtime-opt
maxtime-opt is present. Both MUST NOT be present." Removal of is present. Both MUST NOT be present." Removal of the second
the second normative sentence and instead addition of following normative sentence and instead addition of following new paragraph
new paragraph to the end of this section: "Within an 'a=dcmap' to the end of this section: "Within an 'a=dcmap' attribute line's
attribute line's 'dcmap-opt' value either only one 'maxretr-opt' 'dcmap-opt' value only one 'maxretr-opt' parameter or one
parameter or one 'maxtime-opt' parameter is present. Both MUST 'maxtime-opt' parameter is present. Both MUST NOT be present."
NOT be present."
o In Section 5.1.7 replacement of the first sentence "The 'ordered' o In Section 5.1.7 replacement of the first sentence "The 'ordered'
parameter with value "true" indicates that DATA chunks in the parameter with value "true" indicates that DATA chunks in the
channel MUST be dispatched to the upper layer by the receiver channel MUST be dispatched to the upper layer by the receiver
while preserving the order." with "The 'ordered' parameter with while preserving the order." with "The 'ordered' parameter with
value "true" indicates that the receiver MUST dispatch DATA chunks value "true" indicates that the receiver MUST dispatch DATA chunks
in the data channel to the upper layer while preserving the in the data channel to the upper layer while preserving the
order.". order.".
o In Section 6.3's first paragraph replacement of the one occurrence o In Section 6.3's first paragraph replacement of the one occurrence
skipping to change at page 34, line 32 skipping to change at page 34, line 29
[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
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018. (work in progress), February 2018.
[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-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015.
[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 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<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
Transmission Protocol (SCTP) Stream Reconfiguration", Transmission Protocol (SCTP) Stream Reconfiguration",
RFC 6525, DOI 10.17487/RFC6525, February 2012, RFC 6525, DOI 10.17487/RFC6525, February 2012,
<https://www.rfc-editor.org/info/rfc6525>. <https://www.rfc-editor.org/info/rfc6525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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-14 (work in progress), August 2016. clue-datachannel-15 (work in progress), August 2018.
[I-D.ietf-mmusic-dtls-sdp] [I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Session Description Protocol Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-32 (work in progress), October draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017. 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.
[I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015.
[IANA-SDP-Parameters]
"Session Description Protocol (SDP) Parameters", Internet
Assigned Numbers Authority Protocol Assignments Session
Description Protocol (SDP) Parameters,
<http://www.iana.org/assignments/sdp-parameters/
sdp-parameters.xhtml>.
[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>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
"The Message Session Relay Protocol (MSRP)", RFC 4975, "The Message Session Relay Protocol (MSRP)", RFC 4975,
DOI 10.17487/RFC4975, September 2007, DOI 10.17487/RFC4975, September 2007,
<https://www.rfc-editor.org/info/rfc4975>. <https://www.rfc-editor.org/info/rfc4975>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>. <https://www.rfc-editor.org/info/rfc6455>.
[WebRtcAPI] [WebRtcAPI]
 End of changes. 34 change blocks. 
90 lines changed or deleted 82 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/