draft-ietf-mmusic-data-channel-sdpneg-04.txt   draft-ietf-mmusic-data-channel-sdpneg-05.txt 
MMUSIC K. Drage, Ed. MMUSIC K. Drage, Ed.
Internet-Draft M. Makaraju Internet-Draft M. Makaraju
Intended status: Standards Track J. Stoetzer-Bradler Intended status: Standards Track J. Stoetzer-Bradler
Expires: February 5, 2016 Alcatel-Lucent Expires: April 7, 2016 Alcatel-Lucent
R. Ejzak R. Ejzak
J. Marcon J. Marcon
Unaffiliated Unaffiliated
August 4, 2015 October 5, 2015
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-04 draft-ietf-mmusic-data-channel-sdpneg-05
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, where each data channel might be used to channels over SCTP, where each data channel might be used to
transport other protocols, called sub-protocols. Data channel setup transport other protocols, called sub-protocols. Data channel setup
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 February 5, 2016. This Internet-Draft will expire on April 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 5 5. SDP Offer/Answer Negotiation . . . . . . . . . . . . . . . . 5
5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. SDP Syntax . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. SDP Attribute for Data Channel Parameter Negotiation 5 5.1.1. SDP Attribute for Data Channel Parameter Negotiation 5
5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 5 5.1.1.1. dcmap Attribute . . . . . . . . . . . . . . . . . 5
5.1.1.2. dcmap-stream-id Parameter . . . . . . . . . . . . 7 5.1.1.2. dcmap Multiplexing Category . . . . . . . . . . . 7
5.1.1.3. label Parameter . . . . . . . . . . . . . . . . . 7 5.1.1.3. dcmap-stream-id Parameter . . . . . . . . . . . . 7
5.1.1.4. subprotocol Parameter . . . . . . . . . . . . . . 7 5.1.1.4. label Parameter . . . . . . . . . . . . . . . . . 7
5.1.1.5. max-retr Parameter . . . . . . . . . . . . . . . 7 5.1.1.5. subprotocol Parameter . . . . . . . . . . . . . . 8
5.1.1.6. max-time Parameter . . . . . . . . . . . . . . . 8 5.1.1.6. max-retr Parameter . . . . . . . . . . . . . . . 8
5.1.1.7. ordered Parameter . . . . . . . . . . . . . . . . 8 5.1.1.7. max-time Parameter . . . . . . . . . . . . . . . 8
5.1.2. Sub-Protocol Specific Attributes . . . . . . . . . . 8 5.1.1.8. ordered Parameter . . . . . . . . . . . . . . . . 8
5.1.2. Sub-Protocol Specific Attributes . . . . . . . . . . 9
5.1.2.1. dcsa Attribute . . . . . . . . . . . . . . . . . 9
5.1.2.2. dcsa Multiplexing Category . . . . . . . . . . . 10
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 10 5.2.1. Managing Stream Identifiers . . . . . . . . . . . . . 10
5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 10 5.2.2. Negotiating Data Channel Parameters . . . . . . . . . 11
5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 11 5.2.3. Opening a Data Channel . . . . . . . . . . . . . . . 12
5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 13 5.2.4. Closing a Data Channel . . . . . . . . . . . . . . . 14
5.2.5. Various SDP Offer/Answer Scenarios and Considerations 14 5.2.5. Various SDP Offer/Answer Scenarios and Considerations 15
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 17 8.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 18
8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 18 8.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19
8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Changes against 'draft-ietf-mmusic-data-channel- 10.1. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 18 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 20
10.2. Changes against 'draft-ietf-mmusic-data-channel- 10.2. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 19 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 21
10.3. Changes against 'draft-ietf-mmusic-data-channel- 10.3. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 20 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 22
10.4. Changes against 'draft-ietf-mmusic-data-channel- 10.4. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 23
10.5. Changes against 'draft-ejzak-mmusic-data-channel- 10.5. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 25 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 25
10.6. Changes against '-01' . . . . . . . . . . . . . . . . . 26 10.6. Changes against 'draft-ejzak-mmusic-data-channel-
10.7. Changes against '-00' . . . . . . . . . . . . . . . . . 27 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.7. Changes against '-01' . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.8. Changes against '-00' . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Generic Data Channel Negotiation Aspects When Not Appendix A. Generic Data Channel Negotiation Aspects When Not
Using DCEP . . . . . . . . . . . . . . . . . . . . . 29 Using DCEP . . . . . . . . . . . . . . . . . . . . . 32
A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 30 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 32
A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 30 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 33
A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 30 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 33
A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 31 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 33
A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 32 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 SCTP/DTLS. RTCWeb leaves it open for data channels running on top of SCTP/DTLS. RTCWeb leaves it open for
other applications to use data channels and its in-band DCEP or other other applications to use data channels and its in-band DCEP or other
in-band or out-of-band protocols for creating them. Each data in-band or out-of-band protocols for creating them. 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
through the WebRTC API, or other users of data channel like CLUE, and through the WebRTC API, or other users of data channel like CLUE, and
skipping to change at page 7, line 8 skipping to change at page 7, line 8
a=dcmap:0 a=dcmap:0
a=dcmap:1 subprotocol="BFCP";max-time=60000 a=dcmap:1 subprotocol="BFCP";max-time=60000
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 a=dcmap:3 label="Label 1";ordered=false;max-retr=5
a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000;max-retr=3 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000;max-retr=3
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 either only
one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be
present. Both MUST NOT be present. present. Both MUST NOT be present.
5.1.1.2. dcmap-stream-id Parameter 5.1.1.2. dcmap Multiplexing Category
Multiplexing characteristics of SDP attributes are described in
[I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute
multiplexing categories are introduced there.
The multiplexing category of the "a=dcmap:" attribute is SPECIAL.
Usage of this attribute is only applicable when associated with
UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines.
As the usage of multiple SCTP associations on top of a single DTLS
connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no
multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/
SCTP proto values. If future extensions of
[I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of
multiple SCTP associations of top of a single DTLS connection, then
multiplexing rules for the "a=dcmap:" attribute need to be defined as
well, for instance in an extension of this SDP based data channel
negotiation specification.
5.1.1.3. 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.1.3. label Parameter 5.1.1.4. label Parameter
The 'label' parameter indicates the name of the channel. It The 'label' parameter indicates the name of the channel. It
represents a label that can be used to distinguish, in the context of represents a label that can be used to distinguish, in the context of
the WebRTC API [WebRtcAPI], an RTCDataChannel object from other the WebRTC API [WebRtcAPI], an RTCDataChannel object from other
RTCDataChannel objects. This parameter maps to the 'Label' parameter RTCDataChannel objects. This parameter maps to the 'Label' parameter
defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is
optional. If it is not present, then its value defaults to the empty optional. If it is not present, then its value defaults to the empty
string. string.
Note: The empty string MAY also be explicitly used as 'label' value, Note: The empty string MAY also be explicitly used as 'label' value,
such that 'label=""' is equivalent to the 'label' parameter not being such that 'label=""' is equivalent to the 'label' parameter not being
present at all. [I-D.ietf-rtcweb-data-protocol] allows the present at all. [I-D.ietf-rtcweb-data-protocol] allows the
DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. DATA_CHANNEL_OPEN message's 'Label' value to be an empty string.
5.1.1.4. subprotocol Parameter 5.1.1.5. subprotocol Parameter
The 'subprotocol' parameter indicates which protocol the client The 'subprotocol' parameter indicates which protocol the client
expects to exchange via the channel. 'Subprotocol' is an optional expects to exchange via the channel. This parameter maps to the
parameter. If the 'subprotocol' parameter is not present, then its 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol].
value defaults to the empty string. Section 8.1 specifies how new subprotocol parameter values are
registered. 'Subprotocol' is an optional parameter. If the
'subprotocol' parameter is not present, then its value defaults to
the empty string.
5.1.1.5. max-retr Parameter Note: The empty string MAY also be explicitly used as 'subprotocol'
value, such that 'subprotocol=""' is equivalent to the 'subprotocol'
parameter not being present at all. [I-D.ietf-rtcweb-data-protocol]
allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an
empty string.
5.1.1.6. max-retr Parameter
This parameter indicates that the data channel is partially reliable. This parameter indicates that the data channel is partially reliable.
The 'max-retr' parameter indicates the maximal number of times a user The 'max-retr' parameter indicates the maximal number of times a user
message will be retransmitted. The max-retr parameter is optional. message will be retransmitted. The max-retr parameter is optional.
If the max-retr parameter is not present, then the maximal number of If the max-retr parameter is not present, then the maximal number of
retransmissions is determined as per the generic SCTP retransmission retransmissions is determined as per the generic SCTP retransmission
rules as specified in [RFC4960]. This parameter maps to the 'Number rules as specified in [RFC4960]. This parameter maps to the 'Number
of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol].
5.1.1.6. max-time Parameter 5.1.1.7. max-time Parameter
This parameter indicates that the data channel is partially reliable. This parameter indicates that the data channel is partially reliable.
A user message will no longer be transmitted or retransmitted after a A user message will no longer be transmitted or retransmitted after a
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.1.7. ordered Parameter 5.1.1.8. 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 MUST 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].
skipping to change at page 8, line 39 skipping to change at page 9, line 16
In the SDP, each data channel declaration MAY also be followed by In the SDP, each data channel declaration MAY also be followed by
other SDP attributes specific to the sub-protocol in use. Each of other SDP attributes specific to the sub-protocol in use. Each of
these attributes is represented by one new attribute line, and it these attributes is represented by one new attribute line, and it
includes the contents of a media-level SDP attribute already defined includes the contents of a media-level SDP attribute already defined
for use with this (sub)protocol in another IETF specification. Sub- for use with this (sub)protocol in another IETF specification. Sub-
protocol-specific attributes might also be defined for exclusive use protocol-specific attributes might also be defined for exclusive use
with data channel transport, but should use the same syntax described with data channel transport, but should use the same syntax described
here for other sub-protocol-specific attributes. here for other sub-protocol-specific attributes.
5.1.2.1. dcsa Attribute
Each sub-protocol specific SDP attribute that would normally be used Each sub-protocol specific SDP attribute that would normally be used
to negotiate the subprotocol using SDP is replaced with an attribute to negotiate the subprotocol using SDP is replaced with an attribute
of the form "a=dcsa:stream-id original-attribute", where dcsa stands of the form "a=dcsa:stream-id original-attribute", where dcsa stands
for "data channel sub-protocol attribute", stream-id is the SCTP for "data channel sub-protocol attribute", stream-id is the SCTP
stream identifier assigned to this sub-protocol instance, and stream identifier assigned to this sub-protocol instance, and
original-attribute represents the contents of the sub-protocol original-attribute represents the contents of the sub-protocol
related attribute to be included. related attribute to be included.
Formal Syntax: Formal Syntax:
skipping to change at page 10, line 5 skipping to change at page 10, line 24
The same syntax applies to any other SDP attribute required for The same syntax applies to any other SDP attribute required for
negotiation of this instance of the sub-protocol. negotiation of this instance of the sub-protocol.
Note: This document does not provide a complete specification of how Note: This document does not provide a complete specification of how
to negotiate the use of a data channel to transport MSRP. Procedures to negotiate the use of a data channel to transport MSRP. Procedures
specific to each sub-protocol such as MSRP will be documented specific to each sub-protocol such as MSRP will be documented
elsewhere. The use of MSRP is only an example of how the generic elsewhere. The use of MSRP is only an example of how the generic
procedures described herein might apply to a specific sub-protocol. procedures described herein might apply to a specific sub-protocol.
5.1.2.2. dcsa Multiplexing Category
The multiplexing category of the "a=dcsa:" attribute is SPECIAL.
Usage of this attribute is only applicable when associated with
UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines.
As the usage of multiple SCTP associations on top of a single DTLS
connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no
multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/
SCTP proto values. If future extensions of
[I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of
multiple SCTP associations of top of a single DTLS connection, then
multiplexing rules for the "a=dcsa:" attribute need to be defined as
well, for instance in an extension of this SDP based data channel
negotiation specification.
5.2. Procedures 5.2. Procedures
5.2.1. Managing Stream Identifiers 5.2.1. Managing Stream Identifiers
If an SDP offer/answer exchange (could be the initial or a subsequent If an SDP offer/answer exchange (could be the initial or a subsequent
one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media
description being accepted, and if this SDP offer/answer exchange description being accepted, and if this SDP offer/answer exchange
results in the establishment of a new SCTP association, then the SDP results in the establishment of a new SCTP association, then the SDP
offerer owns the even SCTP stream ids of this new SCTP association offerer owns the even SCTP stream ids of this new SCTP association
and the answerer owns the odd SCTP stream identifiers. If this "m" and the answerer owns the odd SCTP stream identifiers. If this "m"
line is removed from the signaling session (its port number set to line is removed from the signaling session (its port number set to
zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/ zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/
SCTP based "m" line is renegotiated later on, then the even and odd SCTP based "m" line is renegotiated later on, then the even and odd
SCTP stream identifier ownership is redetermined as well as described SCTP stream identifier ownership is redetermined as well as described
above. above.
This specification allows simultaneous use of SDP offer/answer and This specification allows simultaneous use of SDP offer/answer and
DCEP negotiation. However, an SCTP stream MUST NOT be referenced in DCEP negotiation. However, an SCTP stream MUST NOT be referenced in
a dcmap or dcsa attribute of an SDP offer/answer exchange if the a "a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange
associated SCTP stream has already been negotiated via DCEP. Stream if the associated SCTP stream has already been negotiated via DCEP.
ids that are not currently used in SDP can be used for DCEP Stream ids that are not currently used in SDP can be used for DCEP
negotiation. Stream id allocation per SDP offer/answer negotiation negotiation. Stream id allocation per SDP offer/answer negotiation
may not align with DTLS role based allocation. This could cause may not align with DTLS role based allocation. This could cause
glare conditions when one side trying to do SDP offer/answer glare conditions when one side trying to do SDP offer/answer
negotiation on a stream id while the other end trying to open a data negotiation on a stream id while the other end trying to open a data
channel on the same stream id using DCEP negotiation. To avoid these channel on the same stream id using DCEP negotiation. To avoid these
glare conditions this specification recommends that the data channel glare conditions this specification recommends that the data channel
stack user always selects stream ids per above described SDP offer/ stack user always selects stream ids per above described SDP offer/
answer rule even when DCEP negotiation is used. To avoid glare answer rule even when DCEP negotiation is used. To avoid glare
conditions, it is possible to come up with a different stream id conditions, it is possible to come up with a different stream id
allocation scheme, but such schemes are outside the scope of this allocation scheme, but such schemes are outside the scope of this
specification. specification.
5.2.2. Negotiating Data Channel Parameters 5.2.2. Negotiating Data Channel Parameters
Conveying a reliable data channel is achieved by including neither Conveying a reliable data channel is achieved by including neither
'max-retr' nor 'max-time' in corresponding SDP offer's or answer's 'max-retr' nor 'max-time' in corresponding SDP offer's or answer's
"a=dcmap" attribute line. Conveying a partially reliable data "a=dcmap:" attribute line. Conveying a partially reliable data
channel is achieved by including only one of 'max-retr' or 'max- channel is achieved by including only one of 'max-retr' or 'max-
time'. By definition max-retr and max-time are mutually exclusive, time'. By definition max-retr and max-time are mutually exclusive,
so at most one of them MAY be present in the "a=dcmap" attribute so at most one of them MAY be present in the "a=dcmap:" attribute
line. If an SDP offer contains both of these parameters then the line. If an SDP offer contains both of these parameters then the
receiver of such an SDP offer MUST reject the SDP offer. If an SDP receiver of such an SDP offer MUST reject the SDP offer. If an SDP
answer contains both of these parameters then the offerer MAY treat answer contains both of these parameters then the offerer MAY treat
it as an error and MAY assume the associated SDP offer/answer failed it as an error and MAY assume the associated SDP offer/answer failed
and MAY take appropriate recovery actions. These recovery options and MAY take appropriate recovery actions. These recovery options
are outside the scope of this specification. are outside the scope of this specification.
The SDP answer SHALL echo the same subprotocol, max-retr, max-time, The SDP answer SHALL echo the same subprotocol, max-retr, max-time,
ordered parameters, if those were present in the offer, and MAY ordered parameters, if those were present in the offer, and MAY
include a label parameter. They MAY appear in any order, which could include a label parameter. They MAY appear in any order, which could
skipping to change at page 12, line 8 skipping to change at page 12, line 44
through SDP offer/answer negotiation performs the following: through SDP offer/answer negotiation performs the following:
o Creates data channels using stream identifiers from the owned set o Creates data channels using stream identifiers from the owned set
(see Section 5.2.1). (see Section 5.2.1).
o Generates a new SDP offer. o Generates a new SDP offer.
o Determines the list of stream identifiers assigned to data o Determines the list of stream identifiers assigned to data
channels opened through SDP offer/answer negotiation. channels opened through SDP offer/answer negotiation.
o Completes the SDP offer with the dcmap and dcsa attributes needed, o Completes the SDP offer with the "a=dcmap:" and "a=dcsa:"
if any, for each SDP offer/answer negotiated data channel, as attributes needed, if any, for each SDP offer/answer negotiated
described in Section 5.1 and in Section 5.2.2. data channel, as described in Section 5.1 and in Section 5.2.2.
o Sends the SDP offer. o Sends the SDP offer.
The peer receiving such an SDP offer performs the following: The peer receiving such an SDP offer performs the following:
o Parses and applies the SDP offer. Note that the typical parser o Parses and applies the SDP offer. Note that the typical parser
normally ignores unknown SDP attributes, which includes data normally ignores unknown SDP attributes, which includes data
channel related attributes. channel related attributes.
o Analyzes the channel parameters and sub-protocol attributes to o Analyzes the channel parameters and sub-protocol attributes to
determine whether to accept each offered data channel. determine whether to accept each offered data channel.
o For accepted data channels, it creates peer instances for the data o For accepted data channels, it creates peer instances for the data
channels with the agent using the channel parameters described in channels with the agent using the channel parameters described in
the SDP offer. Note that the agent is asked to create data the SDP offer. Note that the agent is asked to create data
channels with SCTP stream identifiers contained in the SDP offer channels with SCTP stream identifiers contained in the SDP offer
if the SDP offer is accepted. if the SDP offer is accepted.
o Generates an SDP answer. o Generates an SDP answer.
o Completes the SDP answer with the dcmap and optional dcsa o Completes the SDP answer with the "a=dcmap:" and optional
attributes needed for each SDP offer/answer negotiated data "a=dcsa:" attributes needed for each SDP offer/answer negotiated
channel, as described in Section 5.1 and in Section 5.2.2. data channel, as described in Section 5.1 and in Section 5.2.2.
o Sends the SDP answer. o Sends the SDP answer.
The agent receiving such an SDP answer performs the following: The agent receiving such an SDP answer performs the following:
o Closes any created data channels for which the expected dcmap and o Closes any created data channels for which the expected "a=dcmap:"
dcsa attributes are not present in the SDP answer. and "a=dcsa:" attributes are not present in the SDP answer.
o Applies the SDP answer. o Applies the SDP answer.
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
WebRTC, this is when both data channel stacks have channel parameters WebRTC, this is when both data channel stacks have channel parameters
instantiated. This occurs: instantiated. This occurs:
o At both peers when a data channel is created without an o At both peers when a data channel is created without an
established SCTP association, as soon as the SCTP association is established SCTP association, as soon as the SCTP association is
skipping to change at page 14, line 26 skipping to change at page 15, line 14
channel. This can only be done via new SDP offer/answer, describing channel. This can only be done via new SDP offer/answer, describing
the new sub-protocol and its attributes, only after the corresponding the new sub-protocol and its attributes, only after the corresponding
data channel close acknowledgement is received from the peer (i.e. data channel close acknowledgement is received from the peer (i.e.
SCTP SSN reset of both incoming and outgoing streams is completed). SCTP SSN reset of both incoming and outgoing streams is completed).
This restriction is to avoid the race conditions between arrival of This restriction is to avoid the race conditions between arrival of
"SDP offer which reuses stream" with "SCTP SSN reset which closes "SDP offer which reuses stream" with "SCTP SSN reset which closes
outgoing stream" at the peer. outgoing stream" at the peer.
5.2.5. Various SDP Offer/Answer Scenarios and Considerations 5.2.5. Various SDP Offer/Answer Scenarios and Considerations
SDP offer has no "a=dcmap" attributes SDP offer has no "a=dcmap:" attributes
* Initial SDP offer: No data channel is negotiated yet. The DTLS * Initial SDP offer: No data channel is negotiated yet. The DTLS
connection and SCTP association is negotiated and, if agreed, connection and SCTP association is negotiated and, if agreed,
established as per [I-D.ietf-mmusic-sctp-sdp]. established as per [I-D.ietf-mmusic-sctp-sdp].
* Subsequent SDP offer: All the SDP offer/answer negotiated data * Subsequent SDP offer: All the SDP offer/answer negotiated data
channels are expected be closed now. The DTLS/SCTP association channels are expected be closed now. The DTLS/SCTP association
remains open for SDP offer/answer or DCEP negotiation of data remains open for SDP offer/answer or DCEP negotiation of data
channels. channels.
SDP answer has no "a=dcmap" attributes SDP answer has no "a=dcmap:" attributes
* Initial SDP answer: Either the peer does not support dcmap * Initial SDP answer: Either the peer does not support "a=dcmap:"
attributes or it rejected all the data channels. In either attributes or it rejected all the data channels. In either
case the offerer closes all the SDP offer/answer negotiated case the offerer closes all the SDP offer/answer negotiated
data channels that were open at the time of initial offer. The data channels that were open at the time of initial offer. The
DTLS connection and SCTP association will still be setup. DTLS connection and SCTP association will still be setup.
* Subsequent SDP answer: All the SDP offer/answer negotiated data * Subsequent SDP answer: All the SDP offer/answer negotiated data
channels are expected be closed now. The DTLS/SCTP association channels are expected be closed now. The DTLS/SCTP association
remains open for future SDP offer/answer or DCEP negotiation of remains open for future SDP offer/answer or DCEP negotiation of
data channels. data channels.
SDP offer has no "a=dcsa" attributes for a data channel. SDP offer has no "a=dcsa:" attributes for a data channel.
* This is allowed and indicates there are no sub-protocol * This is allowed and indicates there are no sub-protocol
parameters to convey. parameters to convey.
SDP answer has no "a=dcsa" attributes for a data channel. SDP answer has no "a=dcsa:" attributes for a data channel.
* This is allowed and indicates there are no sub-protocol * This is allowed and indicates there are no sub-protocol
parameters to convey in the SDP answer. The number of dcsa parameters to convey in the SDP answer. The number of
attributes in the SDP answer does not have to match the number "a=dcsa:" attributes in the SDP answer does not have to match
of dcsa attributes in the SDP offer. the number of "a=dcsa:" attributes in the SDP offer.
6. Examples 6. Examples
SDP offer: SDP offer:
m=application 10001 UDP/DTLS/SCTP webrtc-datachannel m=application 10001 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 10.10.10.1 c=IN IP4 10.10.10.1
a=max-message-size:100000 a=max-message-size:100000
a=sctp-port:5000 a=sctp-port:5000
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
skipping to change at page 15, line 42 skipping to change at page 16, line 32
a=sctp-port:5002 a=sctp-port:5002
a=setup:passive a=setup:passive
a=connection:new a=connection:new
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
Figure 1: Example 1 Figure 1: Example 1
In the above example the SDP answerer rejected the data channel with In the above example the SDP answerer rejected the data channel with
stream id 0 either for explicit reasons or because it does not 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 10.10.10.1 c=IN IP4 10.10.10.1
a=max-message-size:100000 a=max-message-size:100000
a=sctp-port:5000 a=sctp-port:5000
a=setup:actpass a=setup:actpass
a=connection:new a=connection:new
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
a=dcmap:0 subprotocol="BFCP";label="BFCP" a=dcmap:0 subprotocol="BFCP";label="BFCP"
a=dcmap:2 subprotocol="MSRP";label="MSRP" a=dcmap:2 subprotocol="MSRP";label="MSRP"
a=dcsa:2 accept-types:message/cpim text/plain text/ a=dcsa:2 accept-types:message/cpim text/plain
a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc
SDP answer: SDP answer:
m=application 10002 UDP/DTLS/SCTP webrtc-datachannel m=application 10002 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 10.10.10.2 c=IN IP4 10.10.10.2
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=connection:new a=connection:new
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
skipping to change at page 18, line 20 skipping to change at page 19, line 20
This document assigns no new values to this table. This document assigns no new values to this table.
NOTE to RFC Editor: Please replace "XXXX" with the number of this NOTE to RFC Editor: Please replace "XXXX" with the number of this
RFC. RFC.
8.2. New SDP Attributes 8.2. New SDP Attributes
8.2.1. dcmap 8.2.1. dcmap
[Editor's note: This section still needs to be completed.] NOTE to RFC Editor: Please replace "XXXX" with the number of this
RFC.
This document defines a new SDP media-level attribute "a=dcmap:" as
follows:
+---------------------+-----------------------------------------+
| Attribute name: | dcmap |
| Type of attribute: | media |
| Mux category: | SPECIAL |
| Charset Dependent: | No |
| Purpose: | Define data channel specific parameters |
| Appropriate values: | As defined in Section 5.1.1 |
| Contact name: | Maridi R. Makaraju (Raju) |
| Contact e-mail: | Raju.Makaraju@alcatel-lucent.com |
| Reference: | RFCXXXX |
+---------------------+-----------------------------------------+
8.2.2. dcsa 8.2.2. dcsa
[Editor's note: This section still needs to be completed.] NOTE to RFC Editor: Please replace "XXXX" with the number of this
RFC.
This document defines a new SDP media-level attribute "a=dcsa:" as
follows:
+---------------------+---------------------------------------------+
| Attribute name: | dcsa |
| Type of attribute: | media |
| Mux category: | SPECIAL |
| Charset Dependent: | No |
| Purpose: | Define data channel sub-protocol specific |
| | attributes |
| Appropriate values: | As defined in Section 5.1.2 |
| Contact name: | Maridi R. Makaraju (Raju) |
| Contact e-mail: | Raju.Makaraju@alcatel-lucent.com |
| Reference: | RFCXXXX |
+---------------------+---------------------------------------------+
9. Acknowledgments 9. Acknowledgments
The authors wish to acknowledge the borrowing of ideas from other The authors wish to acknowledge the borrowing of ideas from other
internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley
and Gavin Llewellyn, and to thank Roni Even, Christian Groves, and Gavin Llewellyn, and to thank Roni Even, Christian Groves,
Christer Holmberg, Paul Kyzivat, Jonathan Lennox, and Uwe Christer Holmberg, Paul Kyzivat, Jonathan Lennox, and Uwe
Rauschenbach for their invaluable comments. Rauschenbach for their invaluable comments.
10. CHANGE LOG 10. CHANGE LOG
10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' 10.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04'
o In Section 5.1.1.5 the first (and only) paragraph was "The
'subprotocol' parameter indicates which protocol the client
expects to exchange via the channel. 'Subprotocol' is an optional
parameter. If the 'subprotocol' parameter is not present, then
its value defaults to the empty string." Replacement of this
paragraph with following two paragraphs:
* The 'subprotocol' parameter indicates which protocol the client
expects to exchange via the channel. This parameter maps to
the 'Protocol' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. Section 8.1 specifies how new
subprotocol parameter values are registered. 'Subprotocol' is
an optional parameter. If the 'subprotocol' parameter is not
present, then its value defaults to the empty string.
* Note: The empty string MAY also be explicitly used as
'subprotocol' value, such that 'subprotocol=""' is equivalent
to the 'subprotocol' parameter not being present at all.
[I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN
message's 'Subprotocol' value to be an empty string.
o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of
normative references.
o Addition of dcmap attribute specific IANA registration
Section 8.2.1.
o Addition of dcsa attribute specific IANA registration
Section 8.2.2.
o Addition of new Section 5.1.1.2 describing the mux category of the
dcmap SDP attribute. This section and the new "a=dcsa:" attribute
related mux category section are similar to the "Mux Category"
sections of the "a=sctp-port:" and "a=max-message-size:"
attributes in [I-D.ietf-mmusic-sctp-sdp].
o Addition of new Section 5.1.2.2 describing the mux category of the
dcsa SDP attribute.
10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03'
o In Section 1 replacement of "RTCWeb leaves it open for other o In Section 1 replacement of "RTCWeb leaves it open for other
applications to use data channels and its in-band DCEP or out-of- applications to use data channels and its in-band DCEP or out-of-
band non-DCEP protocols for creating them" with "... to use data band non-DCEP protocols for creating them" with "... to use data
channels and its in-band DCEP or other in-band or out-of-band channels and its in-band DCEP or other in-band or out-of-band
protocols for creating them". Additionally replacement of "In protocols for creating them". Additionally replacement of "In
particular, the SDP offer generated by the application includes no particular, the SDP offer generated by the application includes no
channel-specific information" with "... generated by the RTCweb channel-specific information" with "... generated by the RTCweb
data channel stack includes no channel-specific information". data channel stack includes no channel-specific information".
skipping to change at page 19, line 31 skipping to change at page 22, line 15
data channels if DCEP is not used." data channels if DCEP is not used."
o In Section 5.1.1 replacement of "The intention of exchanging these o In Section 5.1.1 replacement of "The intention of exchanging these
attributes is to create data channels on both the peers with the attributes is to create data channels on both the peers with the
same set of attributes without actually using the DCEP same set of attributes without actually using the DCEP
[I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging
these attributes is to create, on two peers, without use of DCEP these attributes is to create, on two peers, without use of DCEP
[I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely
directed data channels having the same set of attributes". directed data channels having the same set of attributes".
o In Section 5.1.1.5 replacement of "The 'max-retr' parameter o In Section 5.1.1.6 replacement of "The 'max-retr' parameter
indicates the maximal number a user message will be retransmitted" indicates the maximal number a user message will be retransmitted"
with "The 'max-retr' parameter indicates the maximal number of with "The 'max-retr' parameter indicates the maximal number of
times a user message will be retransmitted". times a user message will be retransmitted".
o In Section 5.2.1 replacement of "However, an SDP offer/answer o In Section 5.2.1 replacement of "However, an SDP offer/answer
exchange MUST NOT be initiated if the associated SCTP stream is exchange MUST NOT be initiated if the associated SCTP stream is
already negotiated via DCEP" with "However, an SCTP stream MUST already negotiated via DCEP" with "However, an SCTP stream MUST
NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ NOT be referenced in a dcmap or dcsa attribute of an SDP offer/
answer exchange if the associated SCTP stream has already been answer exchange if the associated SCTP stream has already been
negotiated via DCEP". negotiated via DCEP".
o In the examples in Section 6 addition of the previously missing o In the examples in Section 6 addition of the previously missing
colons to the "a=sctp-port" attribute lines. colons to the "a=sctp-port" attribute lines.
10.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' 10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02'
o Move of reference [I-D.ietf-rtcweb-jsep] from the list of o Move of reference [I-D.ietf-rtcweb-jsep] from the list of
normative references to the list of informative references. normative references to the list of informative references.
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-Parameters] contains the lists of IANA registered [IANA-SDP-Parameters] contains the lists of IANA registered
session and media level or media level only SDP attributes." session and media level or media level only SDP attributes."
skipping to change at page 20, line 46 skipping to change at page 23, line 31
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.
10.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' 10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01'
o New Section 4 regarding applicability to SDP offer/answer only. o New Section 4 regarding applicability to SDP offer/answer only.
o Addition of new Section 8.1 "Subprotocol identifiers" as o Addition of new Section 8.1 "Subprotocol identifiers" as
subsection of the "IANA Considerations" related Section 8. Also subsection of the "IANA Considerations" related Section 8. Also
removal of the temporary note "To be completed. As [I-D.ietf- removal of the temporary note "To be completed. As [I-D.ietf-
rtcweb-data-protocol] this document should refer to IANA's rtcweb-data-protocol] this document should refer to IANA's
WebSocket Subprotocol Name Registry defined in [RFC6455]." WebSocket Subprotocol Name Registry defined in [RFC6455]."
o In Section 5.2.2: o In Section 5.2.2:
skipping to change at page 22, line 17 skipping to change at page 24, line 47
o In Section 5.1.1.1 in the definition of the ABNF rule "dcmap-opt" o In Section 5.1.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 "Either only maxretr-opt or
maxtime-opt is present. Both MUST not be present." Removal of maxtime-opt is present. Both MUST not be present." Removal of
the second normative sentence and instead addition of following the second normative sentence and instead addition of following
new paragraph to the end of this section: "Within an 'a=dcmap' new paragraph to the end of this section: "Within an 'a=dcmap'
attribute line's 'dcmap-opt' value either only one 'maxretr-opt' attribute line's 'dcmap-opt' value either only one 'maxretr-opt'
parameter or one 'maxtime-opt' parameter is present. Both MUST parameter or one 'maxtime-opt' parameter is present. Both MUST
NOT be present." NOT be present."
o In Section 5.1.1.7 replacement of the first sentence "The o In Section 5.1.1.8 replacement of the first sentence "The
'ordered' parameter with value "true" indicates that DATA chunks 'ordered' parameter with value "true" indicates that DATA chunks
in the channel MUST be dispatched to the upper layer by the in the channel MUST be dispatched to the upper layer by the
receiver while preserving the order." with "The 'ordered' receiver while preserving the order." with "The 'ordered'
parameter with value "true" indicates that the receiver MUST parameter with value "true" indicates that the receiver MUST
dispatch DATA chunks in the data channel to the upper layer while dispatch DATA chunks in the data channel to the upper layer while
preserving the order.". preserving the order.".
o In Section 5.2.3's first paragraph replacement of the one o In Section 5.2.3's first paragraph replacement of the one
occurrence of "must" with "..., it MUST wait until ...". occurrence of "must" with "..., it MUST wait until ...".
skipping to change at page 23, line 5 skipping to change at page 25, line 36
* In the last but one paragraph replacement of "must" with "The * In the last but one paragraph replacement of "must" with "The
application MUST also close...". application MUST also close...".
o In Section 5.1.2 addition of following note after the formal o In Section 5.1.2 addition of following note after the formal
definition of the 'a=dcsa' attribute: "Note that the above definition of the 'a=dcsa' attribute: "Note that the above
reference to RFC 4566 defines were the attribute definition can be reference to RFC 4566 defines were the attribute definition can be
found; it does not provide any limitation on support of attributes found; it does not provide any limitation on support of attributes
defined in other documents in accordance with this attribute defined in other documents in accordance with this attribute
definition." definition."
10.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' 10.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00'
o In Section 3 "WebRTC data channel" was defined as "A bidirectional o In Section 3 "WebRTC data channel" was defined as "A bidirectional
channel consisting of paired SCTP outbound and inbound streams." channel consisting of paired SCTP outbound and inbound streams."
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.
skipping to change at page 23, line 42 skipping to change at page 26, line 26
o In Section 5.1.1 removal of following note: "Note: This attribute o In Section 5.1.1 removal of following note: "Note: This attribute
is derived from attribute "webrtc-DataChannel", which was defined is derived from attribute "webrtc-DataChannel", which was defined
in old version 03 of the following draft, but which was removed in old version 03 of the following draft, but which was removed
along with any support for SDP external negotiation in subsequent along with any support for SDP external negotiation in subsequent
versions: [I-D.ietf-mmusic-sctp-sdp]." versions: [I-D.ietf-mmusic-sctp-sdp]."
o Insertion of following new sentence to the beginning of o Insertion of following new sentence to the beginning of
Section 5.1.1.1: "dcmap is a media level attribute having Section 5.1.1.1: "dcmap is a media level attribute having
following ABNF syntax:" following ABNF syntax:"
o Insertion of new Section 5.1.1.2 containing the dcmap-stream-id o Insertion of new Section 5.1.1.3 containing the dcmap-stream-id
specifying sentence, which previously was placed right before the specifying sentence, which previously was placed right before the
formal ABNF rules. Removal of the sentence 'Stream is a mandatory formal ABNF rules. Removal of the sentence 'Stream is a mandatory
parameter and is noted directly after the "a=dcmap:" attribute's parameter and is noted directly after the "a=dcmap:" attribute's
colon' as this information is part of the ABNF specification. colon' as this information is part of the ABNF specification.
o In Section 5.1.1.1 modification of the 'ordering-value' values o In Section 5.1.1.1 modification of the 'ordering-value' values
from "0" or "1" to "true" or "false". Corresponding text from "0" or "1" to "true" or "false". Corresponding text
modifications in Section 5.1.1.7. modifications in Section 5.1.1.8.
o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred
to rule name "escaped-char", which was not defined. Instead a to rule name "escaped-char", which was not defined. Instead a
rule with name "escaped" was defined. Renamed that rule's name to rule with name "escaped" was defined. Renamed that rule's name to
"escaped-char". "escaped-char".
o Insertion of a dedicated note right after the "a=dcmap:4" o Insertion of a dedicated note right after the "a=dcmap:4"
attribute example in Section 5.1.1.1 regarding the non-printable attribute example in Section 5.1.1.1 regarding the non-printable
"escaped-char" character within the "label" value. "escaped-char" character within the "label" value.
skipping to change at page 25, line 39 skipping to change at page 28, line 22
to handle cases where a successful SDP answer is not received, in to handle cases where a successful SDP answer is not received, in
which case the state of the session SHOULD be kept per the last which case the state of the session SHOULD be kept per the last
successful SDP offer/answer." successful SDP offer/answer."
o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects
Section 5.1.1 contained already procedural descriptions related to Section 5.1.1 contained already procedural descriptions related to
data channel reliability negotiation. Creation of new data channel reliability negotiation. Creation of new
Section 5.2.2 and moval of reliability negotiation related text to Section 5.2.2 and moval of reliability negotiation related text to
this new section. this new section.
10.5. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' 10.6. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02'
o Removal of note "[ACTION ITEM]" from section "subprotocol o Removal of note "[ACTION ITEM]" from section "subprotocol
parameter". As [I-D.ietf-rtcweb-data-protocol] this document parameter". As [I-D.ietf-rtcweb-data-protocol] this document
should refer to IANA's WebSocket Subprotocol Name Registry defined should refer to IANA's WebSocket Subprotocol Name Registry defined
in [RFC6455]. in [RFC6455].
o In whole document, replacement of "unreliable" with "partially o In whole document, replacement of "unreliable" with "partially
reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in
[I-D.ietf-rtcweb-data-protocol] in most places. [I-D.ietf-rtcweb-data-protocol] in most places.
skipping to change at page 26, line 41 skipping to change at page 29, line 24
o In the "Examples" section, in the first two SDP offer examples in o In the "Examples" section, in the first two SDP offer examples in
the a=dcmap attribute lines 'label="BGCP"' was replaced with the a=dcmap attribute lines 'label="BGCP"' was replaced with
'label="BFCP"'. 'label="BFCP"'.
o In all examples, the "m" line proto value "DTLS/SCTP" was replaced o In all examples, the "m" line proto value "DTLS/SCTP" was replaced
with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were
replaced with "a=max-message-size" attribute lines, as per draft- replaced with "a=max-message-size" attribute lines, as per draft-
ietf-mmusic-sctp-sdp-12. ietf-mmusic-sctp-sdp-12.
10.6. Changes against '-01' 10.7. Changes against '-01'
o Formal syntax for dcmap and dcsa attribute lines. o Formal syntax for dcmap and dcsa attribute lines.
o Making subprotocol as an optional parameter in dcmap. o Making subprotocol as an optional parameter in dcmap.
o Specifying disallowed parameter combinations for max-time and max- o Specifying disallowed parameter combinations for max-time and max-
retr. retr.
o Clarifications on WebRTC data channel close procedures. o Clarifications on WebRTC data channel close procedures.
10.7. Changes against '-00' 10.8. Changes against '-00'
o Revisions to identify difference between internal and external o Revisions to identify difference between internal and external
negotiation and their usage. negotiation and their usage.
o Introduction of more generic terminology, e.g. "application" o Introduction of more generic terminology, e.g. "application"
instead of "browser". instead of "browser".
o Clarification of how "max-retr and max-time affect the usage of o Clarification of how "max-retr and max-time affect the usage of
unreliable and reliable WebRTC data channels. unreliable and reliable WebRTC data channels.
skipping to change at page 28, line 9 skipping to change at page 30, line 39
[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-sctp-sdp] [I-D.ietf-mmusic-sctp-sdp]
Holmberg, C., Loreto, S., and G. Camarillo, "Stream Holmberg, C., Loreto, S., and G. Camarillo, "Stream
Control Transmission Protocol (SCTP)-Based Media Transport Control Transmission Protocol (SCTP)-Based Media Transport
in the Session Description Protocol (SDP)", draft-ietf- in the Session Description Protocol (SDP)", draft-ietf-
mmusic-sctp-sdp-14 (work in progress), March 2015. mmusic-sctp-sdp-15 (work in progress), September 2015.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-10
(work in progress), July 2015.
11.2. Informative References 11.2. Informative References
[I-D.ietf-rtcweb-data-protocol] [I-D.ietf-rtcweb-data-protocol]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel
Establishment Protocol", draft-ietf-rtcweb-data- Establishment Protocol", draft-ietf-rtcweb-data-
protocol-09 (work in progress), January 2015. protocol-09 (work in progress), January 2015.
[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,
 End of changes. 49 change blocks. 
89 lines changed or deleted 221 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/