draft-ietf-mmusic-data-channel-sdpneg-16.txt | draft-ietf-mmusic-data-channel-sdpneg-17.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: June 28, 2018 Nokia | Expires: October 6, 2018 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 | |||
December 25, 2017 | April 4, 2018 | |||
SDP-based Data Channel Negotiation | SDP-based Data Channel Negotiation | |||
draft-ietf-mmusic-data-channel-sdpneg-16 | draft-ietf-mmusic-data-channel-sdpneg-17 | |||
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 June 28, 2018. | This Internet-Draft will expire on October 6, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 | 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 | |||
5. SDP Data Channel attributes . . . . . . . . . . . . . . . . . 6 | 5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6 | |||
5.1. SDP data channel attributes . . . . . . . . . . . . . . . 6 | 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 | |||
5.1.1. SDP Attribute for Data Channel Parameter Negotiation 6 | 5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 7 | |||
5.1.2. Other Media Level Attributes . . . . . . . . . . . . 10 | 5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8 | |||
5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8 | ||||
5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 | ||||
5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9 | ||||
5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 | ||||
5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 | ||||
5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 10 | ||||
5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10 | ||||
5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 | ||||
5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11 | ||||
5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 | ||||
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 | 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 | |||
6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 12 | 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 12 | |||
6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 | 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 | |||
6.3. Generating initial Offer . . . . . . . . . . . . . . . . 14 | 6.3. Generating Initial Offer . . . . . . . . . . . . . . . . 14 | |||
6.4. Generating SDP answer . . . . . . . . . . . . . . . . . . 15 | 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 | |||
6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 | 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 | |||
6.6. Closing a Data Channel . . . . . . . . . . . . . . . . . 16 | 6.6. Subsequent Offers . . . . . . . . . . . . . . . . . . . . 16 | |||
6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 16 | ||||
6.7. Various SDP Offer/Answer Scenarios and Considerations . . 17 | 6.7. Various SDP Offer/Answer Scenarios and Considerations . . 17 | |||
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | |||
9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 22 | 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 22 | |||
9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 22 | 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 22 | |||
9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 22 | 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 23 | 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 23 | 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 23 | |||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
skipping to change at page 5, line 34 ¶ | skipping to change at page 5, line 42 ¶ | |||
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. If an SDP offer/answer exchange is 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, then the | |||
data channel subprotocols may be identified by the values of the | data channel subprotocols may be identified by the values of the | |||
"subprotocol" parameters of the SDP "a=dcmap" attribute as | "subprotocol" parameters of the SDP "a=dcmap" attribute as | |||
described in Section 5.1.1.5. 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. | |||
Peer: From the perspective of one of the agents in a session, its | Peer: From the perspective of one of the agents in a session, its | |||
skipping to change at page 6, line 15 ¶ | skipping to change at page 6, line 23 ¶ | |||
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 section defines an SDP extension by which two clients can | ||||
negotiate data channel-specific and subprotocol-specific parameters | ||||
without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP | ||||
extension only defines usage in the context of SDP offer/answer. | ||||
Appendix A provides information how data channels work in general and | This sections defines new SDP media-level attributes, that can be | |||
especially summarizes some key aspects, which should be considered | used together with the SDP Offer/Answer mechanism to negotiate data | |||
for the negotiation of data channels if DCEP is not used. | channel-specific and subprotocol-specific parameters, without the | |||
usage of DCEP [I-D.ietf-rtcweb-data-protocol]. | ||||
5.1. SDP data channel attributes | Note: Appendix A provides information how data channels work in | |||
general and especially summarizes some key aspects, which should be | ||||
considered for the negotiation of data channels if DCEP is not used. | ||||
Two new SDP attributes are defined to support SDP offer/answer | Two new SDP attributes are defined to support SDP offer/answer | |||
negotiation of data channels. The first attribute provides for | negotiation of data channels. The first attribute provides for | |||
negotiation of channel-specific parameters. The second attribute | negotiation of channel-specific parameters. The second attribute | |||
provides for negotiation of subprotocol-specific parameters. | provides for negotiation of subprotocol-specific parameters. | |||
5.1.1. SDP Attribute for Data Channel Parameter Negotiation | 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. The attribute specifies the following parameters for a | negotiated. | |||
data channel: SCTP stream identifier, subprotocol, label, maximal | ||||
number of retransmissions, maximal retransmission time, order of | ||||
delivery, and priority. | ||||
The intention in exchanging this attribute is to create, on two | The intention in exchanging this attribute is to create, on two | |||
peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched | peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched | |||
data channels as pairs of oppositely directed SCTP streams having the | data channels as pairs of oppositely directed SCTP streams having the | |||
same set of attributes. It is assumed that the data channel | same set of attributes. It is assumed that the data channel | |||
properties (reliable/partially reliable, ordered/unordered) are | properties (reliable/partially reliable, ordered/unordered) are | |||
suitable per the subprotocol transport requirements. | suitable per the subprotocol transport requirements. | |||
5.1.1.1. dcmap Attribute | 5.1.1. DCMAP Attribute Syntax | |||
"a=dcmap:" is a media level attribute having 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 | |||
Value: dcmap-value | Value: dcmap-value | |||
Usage Level: media | Usage Level: media | |||
skipping to change at page 8, line 28 ¶ | skipping to change at page 8, line 28 ¶ | |||
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 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 Multiplexing Category | 5.1.2. Dcmap-stream-id Parameter | |||
Multiplexing characteristics of SDP attributes are described in | ||||
[I-D.ietf-mmusic-sdp-mux-attributes]. | ||||
The multiplexing category of the "a=dcmap:" attribute is SPECIAL. | ||||
As the usage of multiple SCTP associations on top of a single DTLS | ||||
association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no | ||||
"a=dcmap:" attribute 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 on top of a single DTLS association, or | ||||
how to add multiple SCTP associations to one BUNDLE group, then | ||||
multiplexing rules for the "a=dcmap:" attribute need to be defined as | ||||
well, for instance in an extension of this SDP offer/answer 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.4. 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 | |||
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 a 'label' | Note: The empty string MAY also be explicitly used as a 'label' | |||
value, such that 'label=""' is equivalent to the 'label' parameter | value, such that 'label=""' is equivalent to the 'label' parameter | |||
not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the | not being 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.5. subprotocol Parameter | 5.1.4. Subprotocol Parameter | |||
The 'subprotocol' parameter indicates which protocol the client | The 'subprotocol' parameter indicates which protocol the client | |||
expects to exchange via the channel. This parameter maps to the | expects to exchange via the channel. This parameter maps to the | |||
'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. | 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. | |||
Section 9.1 specifies how new subprotocol parameter values are | Section 9.1 specifies how new subprotocol parameter values are | |||
registered. 'Subprotocol' is an optional parameter. If the | registered. 'Subprotocol' is an optional parameter. If the | |||
'subprotocol' parameter is not present, then its value defaults to an | 'subprotocol' parameter is not present, then its value defaults to an | |||
empty string. | empty string. | |||
Note: The empty string MAY also be explicitly used as 'subprotocol' | Note: The empty string MAY also be explicitly used as 'subprotocol' | |||
value, such that 'subprotocol=""' is equivalent to the 'subprotocol' | value, such that 'subprotocol=""' is equivalent to the 'subprotocol' | |||
parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] | parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] | |||
allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an | allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an | |||
empty string. | empty string. | |||
skipping to change at page 9, line 36 ¶ | skipping to change at page 9, line 16 ¶ | |||
registered. 'Subprotocol' is an optional parameter. If the | registered. 'Subprotocol' is an optional parameter. If the | |||
'subprotocol' parameter is not present, then its value defaults to an | 'subprotocol' parameter is not present, then its value defaults to an | |||
empty string. | empty string. | |||
Note: The empty string MAY also be explicitly used as 'subprotocol' | Note: The empty string MAY also be explicitly used as 'subprotocol' | |||
value, such that 'subprotocol=""' is equivalent to the 'subprotocol' | value, such that 'subprotocol=""' is equivalent to the 'subprotocol' | |||
parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] | parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] | |||
allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an | allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an | |||
empty string. | empty string. | |||
5.1.1.6. max-retr Parameter | 5.1.5. 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.7. max-time Parameter | 5.1.6. 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.8. 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 | 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]. | |||
5.1.1.9. priority Parameter | 5.1.8. Priority Parameter | |||
The 'priority' parameter indicates the data channel's priority | The 'priority' parameter indicates the data channel's priority | |||
relative to the priorities of other data channels, which may | relative to the priorities of other data channels, which may | |||
additionally exist over the same SCTP association. The 'priority' | additionally exist over the same SCTP association. The 'priority' | |||
parameter maps to the 'Priority' parameter defined in | parameter maps to the 'Priority' parameter defined in | |||
[I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is | [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is | |||
optional. In the absence of this parameter "priority=256" is | optional. In the absence of this parameter "priority=256" is | |||
assumed. | assumed. | |||
5.1.2. Other Media Level Attributes | 5.1.9. DCMAP Multiplexing Category | |||
Multiplexing characteristics of SDP attributes are described in | ||||
[I-D.ietf-mmusic-sdp-mux-attributes]. | ||||
The multiplexing category of the "a=dcmap:" attribute is SPECIAL. | ||||
As the usage of multiple SCTP associations on top of a single DTLS | ||||
association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no | ||||
"a=dcmap:" attribute 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 on top of a single DTLS association, or | ||||
how to add multiple SCTP associations to one BUNDLE group, then | ||||
multiplexing rules for the "a=dcmap:" attribute need to be defined as | ||||
well, for instance in an extension of this SDP offer/answer based | ||||
data channel negotiation specification. | ||||
5.2. SDP DCSA Attribute | ||||
In the SDP media description, each data channel declaration MAY also | In the SDP media description, each data channel declaration MAY also | |||
be followed by other media level SDP attributes, which are either | be followed by other media level SDP attributes, which are either | |||
specifically defined for or applied to the subprotocol in use. Each | specifically defined for or applied to the subprotocol in use. Each | |||
of these attributes is represented by one new attribute line, and it | of 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 (Internet Engineering | for use with this (sub)protocol in another IETF (Internet Engineering | |||
Task Force) document. Subprotocol specific attributes MAY also be | Task Force) document. Subprotocol specific attributes MAY also be | |||
defined for exclusive use with data channel transport, but MUST use | defined for exclusive use with data channel transport, but MUST use | |||
the same syntax described here for other subprotocol related | the same syntax described here for other subprotocol related | |||
attributes. | attributes. | |||
5.1.2.1. dcsa Attribute | ||||
Each SDP attribute, related to the subprotocol, that would normally | Each SDP attribute, related to the subprotocol, that would normally | |||
be used to negotiate the subprotocol using SDP offer/answer is | be used to negotiate the subprotocol using SDP offer/answer is | |||
replaced with an attribute of the form "a=dcsa:stream-id original- | replaced with an attribute of the form "a=dcsa:stream-id original- | |||
attribute", where dcsa stands for "data channel subprotocol | attribute", where dcsa stands for "data channel subprotocol | |||
attribute", stream-id is the SCTP stream identifier assigned to this | attribute", stream-id is the SCTP stream identifier assigned to this | |||
subprotocol instance, and original-attribute represents the contents | subprotocol instance, and original-attribute represents the contents | |||
of the subprotocol related attribute to be included. | of the subprotocol related attribute to be included. | |||
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 subprotocol. | negotiation of this instance of the subprotocol. | |||
5.2.1. DCSA Syntax | ||||
Formal Syntax: | Formal Syntax: | |||
Name: dcsa | Name: dcsa | |||
Value: dcsa-value | Value: dcsa-value | |||
Usage Level: media | Usage Level: media | |||
Charset Dependent: no | Charset Dependent: no | |||
Syntax: | Syntax: | |||
dcsa-value = stream-id SP attribute | dcsa-value = stream-id SP attribute | |||
attribute = <from-RFC4566> | attribute = <from-RFC4566> | |||
Example (other MSRP related SDP attributes are omitted for brevity): | Example: | |||
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 above reference to [RFC4566] defines where the | |||
attribute definition can be found; it does not provide any limitation | attribute definition can be found; it does not provide any limitation | |||
on support of attributes defined in other documents in accordance | on support of attributes defined in other documents in accordance | |||
with this attribute definition. Note however that not all SDP | with this attribute definition. Note however that not all SDP | |||
attributes are suitable as a "a=dcsa:" parameter. | attributes are suitable as a "a=dcsa:" parameter. | |||
[IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned | [IANA-SDP-Parameters] contains the lists of IANA (Internet Assigned | |||
Numbers Authority) registered session and media level or media level | Numbers Authority) registered session and media level or media level | |||
skipping to change at page 12, line 13 ¶ | skipping to change at page 12, line 17 ¶ | |||
in a "a=dcsa" attribute. | in a "a=dcsa" attribute. | |||
There may be cases, where the usage of a subprotocol related media | There may be cases, where the usage of a subprotocol related media | |||
level attribute depends on the subprotocol's transport protocol. In | level attribute depends on the subprotocol's transport protocol. In | |||
such cases the subprotocol related usage of the attribute is expected | such cases the subprotocol related usage of the attribute is expected | |||
to be described for the data channel transport. A data channel | to be described for the data channel transport. A data channel | |||
specific usage of a subprotocol attribute is expected to be specified | specific usage of a subprotocol attribute is expected to be specified | |||
in the same document that registers the subprotocol's identifier for | in the same document that registers the subprotocol's identifier for | |||
data channel usage as described in Section 9.1. | data channel usage as described in Section 9.1. | |||
5.1.2.2. dcsa Multiplexing Category | 5.2.2. DCSA Multiplexing Category | |||
The multiplexing category of the "a=dcsa:" attribute is SPECIAL. | The multiplexing category of the "a=dcsa:" attribute is SPECIAL. | |||
As the usage of multiple SCTP associations on top of a single DTLS | As the usage of multiple SCTP associations on top of a single DTLS | |||
association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no | association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no | |||
"a=dcsa:" attribute multiplexing rules are specified for the | "a=dcsa:" attribute multiplexing rules are specified for the | |||
UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions | 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 | of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of | |||
multiple SCTP associations on top of a single DTLS association, or | multiple SCTP associations on top of a single DTLS association, or | |||
how to add multiple SCTP associations to one BUNDLE group, then | how to add multiple SCTP associations to one BUNDLE group, then | |||
skipping to change at page 14, line 23 ¶ | skipping to change at page 14, line 23 ¶ | |||
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> | |||
6.3. Generating initial Offer | 6.3. Generating Initial Offer | |||
The procedure for opening a data channel using SDP offer/answer | ||||
negotiation starts with the agent preparing to send an SDP offer. If | ||||
a peer receives an SDP offer before starting to send a new SDP offer | ||||
with data channels that are to be SDP offer/answer negotiated, or | ||||
loses an SDP offer glare resolution procedure in this case, it MUST | ||||
wait until the ongoing SDP offer/answer completes before resuming the | ||||
SDP offer/answer negotiation procedure. | ||||
The agent that intends to send an SDP offer to create data channels | The agent that intends to send an SDP offer to create data channels | |||
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 6.1). | (see Section 6.1). | |||
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 "a=dcmap:" and "a=dcsa:" | o Generates the SDP offer with the "a=dcmap:" and "a=dcsa:" | |||
attributes needed, if any, for each SDP offer/answer negotiated | attributes needed, if any, for each SDP offer/answer negotiated | |||
data channel, as described in Section 5.1 and in Section 6.2. | data channel, as described in Section 5 and in Section 6.2. | |||
o If it adds "a=dcsa" attributes to the SDP offer, then it SHOULD | o The "a=dcsa" attributes to the SDP offer SHOULD have the | |||
add the subprotocol parameter to the "a=dcmap" attribute with a | subprotocol parameters to the "a=dcmap" attribute with a non-empty | |||
non-empty subprotocol identifier. | subprotocol identifier. | |||
o Sends the SDP offer. | o Sends the SDP offer. | |||
6.4. Generating SDP answer | 6.4. Generating SDP Answer | |||
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, taking into account the | o Parses and applies the SDP offer, taking into account the | |||
considerations discussed in Section 6.7. | considerations discussed in Section 6.7. | |||
o Analyzes the channel parameters and subprotocol attributes to | o Analyzes the channel parameters and subprotocol attributes to | |||
determine whether to accept each offered data channel. | determine whether to accept each offered data channel. | |||
o For accepted data channels, the agent MUST create peer instances | o For accepted data channels, the agent MUST create peer instances | |||
for the data channels using the SCTP stream identifiers and | for the data channels using the SCTP stream identifiers and | |||
channel parameters contained in the SDP offer. | channel parameters contained in the SDP offer. | |||
o Generates an SDP answer. | o Generates an SDP answer. | |||
o Completes the SDP answer with the "a=dcmap:" and optional | o Completes the SDP answer with the "a=dcmap:" and optional | |||
"a=dcsa:" attributes needed for each SDP offer/answer negotiated | "a=dcsa:" attributes needed for each SDP offer/answer negotiated | |||
data channel, as described in Section 5.1 and in Section 6.2. | data channel, as described in Section 5 and in Section 6.2. | |||
o Sends the SDP answer. | o Sends the SDP answer. | |||
6.5. Offerer Processing of the SDP Answer | 6.5. Offerer Processing of the SDP Answer | |||
The agent receiving such an SDP answer performs the following: | An offerer receiving a SDP answer performs the following: | |||
o Closes any created data channels as described in Section 6.6 for | o Closes any created data channels as described in Section 6.6.1 for | |||
which the expected "a=dcmap:" and "a=dcsa:" attributes are not | which the expected "a=dcmap:" and "a=dcsa:" attributes are not | |||
present in the SDP answer. | 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: | |||
skipping to change at page 16, line 11 ¶ | skipping to change at page 16, line 5 ¶ | |||
o At the agent sending an SDP offer to create a new SDP offer/answer | o At the agent sending an SDP offer to create a new SDP offer/answer | |||
negotiated data channel for which there is an established SCTP | negotiated data channel for which there is an established SCTP | |||
association, when it receives the SDP answer confirming acceptance | association, when it receives the SDP answer confirming acceptance | |||
of the data channel or when it begins to receive data on the data | of the data channel or when it begins to receive data on the data | |||
channel from the peer, whichever occurs first. | channel from the peer, whichever occurs first. | |||
Note: DCEP is not used, that is neither the SDP offerer nor the SDP | Note: DCEP is not used, that is neither the SDP offerer nor the SDP | |||
answerer send an in-band DCEP DATA_CHANNEL_OPEN message. | answerer send an in-band DCEP DATA_CHANNEL_OPEN message. | |||
6.6. Closing a Data Channel | 6.6. Subsequent Offers | |||
When an application wants to add a data channel it will send a new | ||||
oofer with a new a=dcmap with a new dcmap-stream-id and optionally | ||||
a=dcsa attributes. The offer should include in the offer all | ||||
parameters of the existing channesl. If the offer wants to remove a | ||||
data channel it will remove the attributes with the dcmap-stream-id | ||||
it wants to remove, see the examples in the examples section | ||||
Section 7 | ||||
6.6.1. Closing a Data Channel | ||||
When the application requests the closing of a data channel that was | When the application requests the closing of a data channel that was | |||
negotiated via SDP offer/answer, the data channel stack always | negotiated via SDP offer/answer, the data channel stack always | |||
performs an SCTP SSN reset for this channel. | performs an SCTP SSN reset for this channel. | |||
It is specific to the subprotocol whether this closing MUST in | It is specific to the subprotocol whether this closing MUST in | |||
addition be signaled to the peer via a new SDP offer/answer exchange. | addition be signaled to the peer via a new SDP offer/answer exchange. | |||
The intention to close a data channel can be signaled by sending a | The intention to close a data channel can be signaled by sending a | |||
new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute | new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute | |||
skipping to change at page 19, line 7 ¶ | skipping to change at page 19, line 7 ¶ | |||
attribute is known, but whose subprotocol attribute semantic is | attribute is known, but whose subprotocol attribute semantic is | |||
not known for the data channel transport case. | not known for the data channel transport case. | |||
* The receiver of such an SDP offer or answer SHOULD ignore this | * The receiver of such an SDP offer or answer SHOULD ignore this | |||
entire "a=dcsa" attribute line. | entire "a=dcsa" attribute line. | |||
7. Examples | 7. Examples | |||
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 IP6 IP6 2001:db8::3 | |||
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=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=tls-id:abc3de65cddef001be82 | a=tls-id:abc3de65cddef001be82 | |||
a=dcmap:0 subprotocol="BFCP";label="BFCP" | a=dcmap:0 subprotocol="BFCP";label="BFCP" | |||
SDP answer: | SDP answer: | |||
m=application 10002 UDP/DTLS/SCTP webrtc-datachannel | m=application 10002 UDP/DTLS/SCTP webrtc-datachannel | |||
c=IN IP4 192.0.2.2 | 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 above example the SDP answerer rejected the data channel with | |||
skipping to change at page 23, line 6 ¶ | skipping to change at page 23, line 6 ¶ | |||
9.2.1. dcmap | 9.2.1. dcmap | |||
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. | |||
This document defines a new SDP media-level attribute "a=dcmap:" as | This document defines a new SDP media-level attribute "a=dcmap:" as | |||
follows: | follows: | |||
+-----------------------+-------------------------------------------+ | +-----------------------+-------------------------------------------+ | |||
| Contact name: | MMUSIC Chairs | | | Contact name: | IESG Chairs | | |||
| Contact email: | mmusic-chairs@ietf.org | | | Contact email: | iesg@ietf.org | | |||
| Attribute name: | dcmap | | | Attribute name: | dcmap | | |||
| Attribute syntax: | As per Section 5.1.1.1 | | | Attribute syntax: | As per Section 5.1.1 | | |||
| Attribute semantics: | As per Section 5.1.1.1 | | | Attribute semantics: | As per Section 5.1.1 | | |||
| Usage level: | media | | | Usage level: | media | | |||
| Charset dependent: | No | | | Charset dependent: | No | | |||
| Purpose: | Define data channel specific parameters | | | Purpose: | Define data channel specific parameters | | |||
| Appropriate values: | As per Section 5.1.1.1 | | | Appropriate values: | As per Section 5.1.1 | | |||
| O/A procedures: | As per Section 6 | | | O/A procedures: | As per Section 6 | | |||
| Mux category: | SPECIAL. See Section 5.1.1.2 | | | Mux category: | SPECIAL. See Section 5.1.9 | | |||
| Reference: | RFCXXXX | | | Reference: | RFCXXXX | | |||
+-----------------------+-------------------------------------------+ | +-----------------------+-------------------------------------------+ | |||
9.2.2. dcsa | 9.2.2. dcsa | |||
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. | |||
This document defines a new SDP media-level attribute "a=dcsa:" as | This document defines a new SDP media-level attribute "a=dcsa:" as | |||
follows: | follows: | |||
+-----------------------+-------------------------------------------+ | +-----------------------+-------------------------------------------+ | |||
| Contact name: | MMUSIC Chairs | | | Contact name: | IESG Chairs | | |||
| Contact email: | mmusic-chairs@ietf.org | | | Contact email: | iesg@ietf.org | | |||
| Attribute name: | dcsa | | | Attribute name: | dcsa | | |||
| Attribute syntax: | As per Section 5.1.2.1 | | | Attribute syntax: | As per Section 5.2.1 | | |||
| Attribute semantics: | As per Section 5.1.2.1 | | | Attribute semantics: | As per Section 5.2.1 | | |||
| Usage level: | media | | | Usage level: | media | | |||
| Charset dependent: | No | | | Charset dependent: | No | | |||
| Purpose: | Define data channel subprotocol specific | | | Purpose: | Define data channel subprotocol specific | | |||
| | attributes | | | | attributes | | |||
| Appropriate values: | As per Section 5.1.2.1 | | | Appropriate values: | As per Section 5.2.1 | | |||
| O/A procedures: | As per Section 6 | | | O/A procedures: | As per Section 6 | | |||
| Mux category: | SPECIAL. See Section 5.1.2.2 | | | Mux category: | SPECIAL. See Section 5.2.2 | | |||
| Reference: | RFCXXXX | | | Reference: | RFCXXXX | | |||
+-----------------------+-------------------------------------------+ | +-----------------------+-------------------------------------------+ | |||
9.3. New Usage Level | 9.3. New Usage Level | |||
This document introduces a new "Data Channel Subprotocol Attribute" | This document introduces a new "Data Channel Subprotocol Attribute" | |||
(dcsa) usage level of the SDP media description to the IANA SDP att- | (dcsa) usage level of the SDP media description to the IANA SDP att- | |||
field registry. SDP attributes that are defined for use at the dcsa | field registry. SDP attributes that are defined for use at the dcsa | |||
usage level only SHALL use the dcsa usage level when registering the | usage level only SHALL use the dcsa usage level when registering the | |||
attribute. If existing media attributes are used in a datachannel | attribute. If existing media attributes are used in a datachannel | |||
subprotocol specific way (Section 5.1.2.1), then a new dcsa usage | subprotocol specific way (Section 5.2.1), then a new dcsa usage level | |||
level MUST be defined for the existing media attribute. Where the | MUST be defined for the existing media attribute. Where the SDP | |||
SDP attribute is applicable to a particular subprotocol/s this SHALL | attribute is applicable to a particular subprotocol/s this SHALL also | |||
also be registered by indicating the applicable subprotocol | be registered by indicating the applicable subprotocol identifiers | |||
identifiers (see Section 9.1) along with the dcsa usage level. E.g. | (see Section 9.1) along with the dcsa usage level. E.g. | |||
+-----------------------+-------------------------------------------+ | +-----------------------+-------------------------------------------+ | |||
| ... | ... | | | ... | ... | | |||
| Usage level: | dcsa(MSRP) | | | Usage level: | dcsa(MSRP) | | |||
| ... | ... | | | ... | ... | | |||
+-----------------------+-------------------------------------------+ | +-----------------------+-------------------------------------------+ | |||
10. Acknowledgments | 10. 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 Flemming Andreasen, Roni Even, | and Gavin Llewellyn, and to thank Flemming Andreasen, Christian | |||
Christian Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, | Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, Jonathan | |||
Jonathan Lennox, Uwe Rauschenbach and Roman Shpount for their | Lennox, Uwe Rauschenbach and Roman Shpount for their invaluable | |||
invaluable comments. | comments. | |||
11. CHANGE LOG | 11. CHANGE LOG | |||
11.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' | 11.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' | |||
o Editorial changes separate sections for offer/answer procedures. | o Editorial changes separate sections for offer/answer procedures. | |||
o Update security section. | o Update security section. | |||
11.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' | 11.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' | |||
skipping to change at page 25, line 35 ¶ | skipping to change at page 25, line 35 ¶ | |||
rules for SCTP based media transport as specified in | rules for SCTP based media transport as specified in | |||
[I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values | [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values | |||
UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels | UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels | |||
could be defined over other SCTP based protocols, such as SCTP | could be defined over other SCTP based protocols, such as SCTP | |||
over IP. However, corresponding potential other "m" line proto | over IP. However, corresponding potential other "m" line proto | |||
values are not considered in this document." | values are not considered in this document." | |||
o Replacement of "DTLS connection" with "DTLS association" | o Replacement of "DTLS connection" with "DTLS association" | |||
throughout the document. | throughout the document. | |||
o In sections Section 5.1.1.2 and Section 5.1.2.2 removal of the | o In sections Section 5.1.9 and Section 5.2.2 removal of the | |||
sentences "This document also does not specify multiplexing rules | sentences "This document also does not specify multiplexing rules | |||
for this attribute for SCTP or SCTP/DTLS proto values". | for this attribute for SCTP or SCTP/DTLS proto values". | |||
o In the text related to "Subsequent SDP answer" in section | o In the text related to "Subsequent SDP answer" in section | |||
Section 6.7 replacement of "The DTLS/SCTP association remains open | Section 6.7 replacement of "The DTLS/SCTP association remains open | |||
..." with "The SCTP association remains open ...". | ..." with "The SCTP association remains open ...". | |||
o In the text after the second SDP answer in section Section 7 | o In the text after the second SDP answer in section Section 7 | |||
replacement of "... (after SCTP/DTLS association is setup)" with | replacement of "... (after SCTP/DTLS association is setup)" with | |||
"... (after the SCTP association is set up)". | "... (after the SCTP association is set up)". | |||
skipping to change at page 26, line 20 ¶ | skipping to change at page 26, line 20 ¶ | |||
o Addition of RFC4566bis draft to list of normative references. | o Addition of RFC4566bis draft to list of normative references. | |||
o Updates of tables in Section 9.2.1 and Section 9.2.2 as per | o Updates of tables in Section 9.2.1 and Section 9.2.2 as per | |||
section 8.2.4 of RFC4566bis draft. | section 8.2.4 of RFC4566bis draft. | |||
o Addition of new Section 9.3. | o Addition of new Section 9.3. | |||
11.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' | 11.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' | |||
o Addition of two new paragraphs to Section 5.1.2.1 regarding | o Addition of two new paragraphs to Section 5.2.1 regarding | |||
subprotocol attribute relationship with transport protocol. | subprotocol attribute relationship with transport protocol. | |||
o Addition of a note to Section 9.1 regarding subprotocols | o Addition of a note to Section 9.1 regarding subprotocols | |||
simultaneously defined for data channel and Websocket usage. | simultaneously defined for data channel and Websocket usage. | |||
o Addition of two further SDP offer/answer considerations to | o Addition of two further SDP offer/answer considerations to | |||
Section 6.7 regarding unknown subprotocol attributes and known | Section 6.7 regarding unknown subprotocol attributes and known | |||
subprotocol attributes with unknown data channel transport related | subprotocol attributes with unknown data channel transport related | |||
semantic. | semantic. | |||
skipping to change at page 26, line 44 ¶ | skipping to change at page 26, line 44 ¶ | |||
in http://www.ietf.org/mail-archive/web/mmusic/current/ | in http://www.ietf.org/mail-archive/web/mmusic/current/ | |||
msg15357.html and http://www.ietf.org/mail- | msg15357.html and http://www.ietf.org/mail- | |||
archive/web/mmusic/current/msg15359.html. | archive/web/mmusic/current/msg15359.html. | |||
11.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' | 11.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' | |||
o In IANA registration Section 9.2.1 and Section 9.2.2 replacement | o In IANA registration Section 9.2.1 and Section 9.2.2 replacement | |||
of contact name and e-mail address with "MMUSIC Chairs" and | of contact name and e-mail address with "MMUSIC Chairs" and | |||
"mmusic-chairs@ietf.org". | "mmusic-chairs@ietf.org". | |||
o In Section 5.1.2.1 replacement of "Thus in the example above, the | o In Section 5.2.1 replacement of "Thus in the example above, the | |||
original attribute line "a=accept- types:text/plain" is | original attribute line "a=accept- types:text/plain" is | |||
represented by the attribute line "a=dcsa:2 accept-types:text/ | represented by the attribute line "a=dcsa:2 accept-types:text/ | |||
plain", which specifies that this instance of MSRP being | plain", which specifies that this instance of MSRP being | |||
transported on the SCTP association using the data channel with | transported on the SCTP association using the data channel with | |||
stream id 2 accepts plain text files." with "... which specifies | stream id 2 accepts plain text files." with "... which specifies | |||
that this instance of the MSRP subprotocol being transported ...". | that this instance of the MSRP subprotocol being transported ...". | |||
o The last paragraph of Section 5.1.2.1 started with "Note: This | o The last paragraph of Section 5.2.1 started with "Note: This | |||
document does not provide a complete specification ...". Removal | document does not provide a complete specification ...". Removal | |||
of "Note:" and move of this paragraph to the introduction in | of "Note:" and move of this paragraph to the introduction in | |||
Section 1 as last paragraph. | Section 1 as last paragraph. | |||
o Section 5.1.2's headline was "Subprotocol Specific Attributes". | o Section 5.2's headline was "Subprotocol Specific Attributes". | |||
Change of this headline to "Other Media Level Attributes" and | Change of this headline to "Other Media Level Attributes" and | |||
adaptations of the first paragraph of this section and the first | adaptations of the first paragraph of this section and the first | |||
paragraph of Section 5.1.2.1 in order to clarify that not only | paragraph of Section 5.2.1 in order to clarify that not only those | |||
those attributes may be encapsulated in a "dcsa" attribute, which | attributes may be encapsulated in a "dcsa" attribute, which are | |||
are specifically defined for the subprotocol, but that also other | specifically defined for the subprotocol, but that also other | |||
attributes may be encapsulated if they are related to the specific | attributes may be encapsulated if they are related to the specific | |||
subprotocol instance. | subprotocol instance. | |||
o Move of the last but one paragraph of Section 5.1.2.1 starting | o Move of the last but one paragraph of Section 5.2.1 starting with | |||
with "The same syntax applies to ..." right in front of the formal | "The same syntax applies to ..." right in front of the formal | |||
syntax definition of the "dcsa" attribute. | syntax definition of the "dcsa" attribute. | |||
o Modifications of the text in Section 5.1.1.2 and Section 5.1.2.2 | o Modifications of the text in Section 5.1.9 and Section 5.2.2 in | |||
in order not to explicitly restrict usage of the "a=dcmap:" and | order not to explicitly restrict usage of the "a=dcmap:" and | |||
"a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ | "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ | |||
SCTP" or "TCP/DTLS/SCTP". | SCTP" or "TCP/DTLS/SCTP". | |||
11.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' | 11.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' | |||
o In Section 5.1.1.5 the first (and only) paragraph was "The | o In Section 5.1.4 the first (and only) paragraph was "The | |||
'subprotocol' parameter indicates which protocol the client | 'subprotocol' parameter indicates which protocol the client | |||
expects to exchange via the channel. 'Subprotocol' is an optional | expects to exchange via the channel. 'Subprotocol' is an optional | |||
parameter. If the 'subprotocol' parameter is not present, then | parameter. If the 'subprotocol' parameter is not present, then | |||
its value defaults to the empty string." Replacement of this | its value defaults to the empty string." Replacement of this | |||
paragraph with following two paragraphs: | paragraph with following two paragraphs: | |||
* The 'subprotocol' parameter indicates which protocol the client | * The 'subprotocol' parameter indicates which protocol the client | |||
expects to exchange via the channel. This parameter maps to | expects to exchange via the channel. This parameter maps to | |||
the 'Protocol' parameter defined in | the 'Protocol' parameter defined in | |||
[I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new | [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new | |||
skipping to change at page 28, line 11 ¶ | skipping to change at page 28, line 11 ¶ | |||
o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of | o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of | |||
normative references. | normative references. | |||
o Addition of dcmap attribute specific IANA registration | o Addition of dcmap attribute specific IANA registration | |||
Section 9.2.1. | Section 9.2.1. | |||
o Addition of dcsa attribute specific IANA registration | o Addition of dcsa attribute specific IANA registration | |||
Section 9.2.2. | Section 9.2.2. | |||
o Addition of new Section 5.1.1.2 describing the mux category of the | o Addition of new Section 5.1.9 describing the mux category of the | |||
dcmap SDP attribute. This section and the new "a=dcsa:" attribute | dcmap SDP attribute. This section and the new "a=dcsa:" attribute | |||
related mux category section are similar to the "Mux Category" | related mux category section are similar to the "Mux Category" | |||
sections of the "a=sctp-port:" and "a=max-message-size:" | sections of the "a=sctp-port:" and "a=max-message-size:" | |||
attributes in [I-D.ietf-mmusic-sctp-sdp]. | attributes in [I-D.ietf-mmusic-sctp-sdp]. | |||
o Addition of new Section 5.1.2.2 describing the mux category of the | o Addition of new Section 5.2.2 describing the mux category of the | |||
dcsa SDP attribute. | dcsa SDP attribute. | |||
11.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' | 11.12. 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 | |||
skipping to change at page 29, line 7 ¶ | skipping to change at page 29, line 7 ¶ | |||
two clients can negotiate data channel-specific and | two clients can negotiate data channel-specific and | |||
subprotocol-specific parameters without using DCEP | subprotocol-specific parameters without using DCEP | |||
[I-D.ietf-rtcweb-data-protocol]. This SDP extension only | [I-D.ietf-rtcweb-data-protocol]. This SDP extension only | |||
defines usage in the context of SDP offer/answer." | defines usage in the context of SDP offer/answer." | |||
* Addition of new paragraph: "Appendix A provides information how | * Addition of new paragraph: "Appendix A provides information how | |||
data channels work in general and especially summarizes some | data channels work in general and especially summarizes some | |||
key aspects, which should be considered for the negotiation of | key aspects, which should be considered for the negotiation of | |||
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 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.6 replacement of "The 'max-retr' parameter | o In Section 5.1.5 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 6.1 replacement of "However, an SDP offer/answer | o In Section 6.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". | |||
skipping to change at page 31, line 40 ¶ | skipping to change at page 31, line 40 ¶ | |||
with "Initial SDP offer: No data channel is negotiated yet. The | with "Initial SDP offer: No data channel is negotiated yet. The | |||
DTLS connection and SCTP association is negotiated and, if agreed, | DTLS 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]." | |||
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 beginning with "[ASSUMPTION]" | o In Appendix A.2.2's sixth paragraph replacement of the two | |||
replacement of the two occurrences of "must" with "MUST". | occurrences of "must" with "MUST". | |||
o In Section 5.1.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 "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.8 replacement of the first sentence "The | o In Section 5.1.7 replacement of the first sentence "The 'ordered' | |||
'ordered' parameter with value "true" indicates that DATA chunks | parameter with value "true" indicates that DATA chunks in the | |||
in the channel MUST be dispatched to the upper layer by the | channel MUST be dispatched to the upper layer by the receiver | |||
receiver while preserving the order." with "The 'ordered' | while preserving the order." with "The 'ordered' parameter with | |||
parameter with value "true" indicates that the receiver MUST | value "true" indicates that the receiver MUST dispatch DATA chunks | |||
dispatch DATA chunks in the data channel to the upper layer while | in the data channel to the upper layer while preserving the | |||
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 | |||
of "must" with "..., it MUST wait until ...". | of "must" with "..., it MUST wait until ...". | |||
o In Section 6.6: | o In Section 6.6.1: | |||
* In the second paragraph replacement of "must" with "... whether | * In the second paragraph replacement of "must" with "... whether | |||
this closing MUST in addition ..." | this closing MUST in addition ..." | |||
* In the third paragraph replacement of the sentence "The port | * In the third paragraph replacement of the sentence "The port | |||
value for the "m" line SHOULD NOT be changed (e.g., to zero) | value for the "m" line SHOULD NOT be changed (e.g., to zero) | |||
when closing a data channel ..." with "The offerer SHOULD NOT | when closing a data channel ..." with "The offerer SHOULD NOT | |||
change the port value for the "m" line (e.g., to zero) when | change the port value for the "m" line (e.g., to zero) when | |||
closing a data channel ...". | closing a data channel ...". | |||
* In the last but two paragraph replacement of the sentence "... | * In the last but two paragraph replacement of the sentence "... | |||
then an SDP offer which excludes this closed data channel | then an SDP offer which excludes this closed data channel | |||
SHOULD be generated." with "... then the client SHOULD generate | SHOULD be generated." with "... then the client SHOULD generate | |||
an SDP offer which excludes this closed data channel.". | an SDP offer which excludes this closed data channel.". | |||
* 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.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." | |||
11.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' | 11.15. 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." | |||
skipping to change at page 33, line 10 ¶ | skipping to change at page 33, line 10 ¶ | |||
document including the document's headline." | document including the document's headline." | |||
o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in | o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in | |||
[I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. | [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. | |||
In particular we expect "webrtc-datachannel" to become a more | In particular we expect "webrtc-datachannel" to become a more | |||
general term.' | general term.' | |||
o Consistent usage of '"m" line' in whole document as per [RFC4566]. | o Consistent usage of '"m" line' in whole document as per [RFC4566]. | |||
o In Section 5.1.1 removal of the example dcmap attribute line | o In Section 5.1 removal of the example dcmap attribute line | |||
'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are | 'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are | |||
already four examples right after the ABNF rules in | already four examples right after the ABNF rules in Section 5.1.1. | |||
Section 5.1.1.1. Corresponding removal of following related note: | Corresponding removal of following related note: "Note: This | |||
"Note: This document does not provide a complete specification of | document does not provide a complete specification of how to | |||
how to negotiate the use of a WebRTC data channel to transport | negotiate the use of a WebRTC data channel to transport BFCP. | |||
BFCP. Procedures specific to each subprotocol such as BFCP will | Procedures specific to each subprotocol such as BFCP will be | |||
be documented elsewhere. The use of BFCP is only an example of | documented elsewhere. The use of BFCP is only an example of how | |||
how the generic procedures described herein might apply to a | the generic procedures described herein might apply to a specific | |||
specific subprotocol." | subprotocol." | |||
o In Section 5.1.1 removal of following note: "Note: This attribute | o In Section 5.1 removal of following note: "Note: This attribute is | |||
is derived from attribute "webrtc-DataChannel", which was defined | derived from attribute "webrtc-DataChannel", which was defined in | |||
in old version 03 of the following draft, but which was removed | old version 03 of the following draft, but which was removed along | |||
along with any support for SDP external negotiation in subsequent | 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: "dcmap is a media level attribute having following | |||
following ABNF syntax:" | ABNF syntax:" | |||
o Insertion of new Section 5.1.1.3 containing the dcmap-stream-id | o Insertion of new Section 5.1.2 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 modification of the 'ordering-value' values from | |||
from "0" or "1" to "true" or "false". Corresponding text | "0" or "1" to "true" or "false". Corresponding text modifications | |||
modifications in Section 5.1.1.8. | in Section 5.1.7. | |||
o In Section 5.1.1.1 the ABNF definition of "quoted-string" referred | o In Section 5.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 regarding the non-printable | |||
"escaped-char" character within the "label" value. | "escaped-char" character within the "label" value. | |||
o In Section 5.1.2's second paragraph replacement of "sctp stream | o In Section 5.2's second paragraph replacement of "sctp stream | |||
identifier" with "SCTP stream identifier". | identifier" with "SCTP stream identifier". | |||
o In first paragraph of Section 6.1 replacement of first two | o In first paragraph of Section 6.1 replacement of first two | |||
sentences 'For the SDP-based external negotiation described in | sentences 'For the SDP-based external negotiation described in | |||
this document, the initial offerer based "SCTP over DTLS" owns by | this document, the initial offerer based "SCTP over DTLS" owns by | |||
convention the even stream identifiers whereas the initial | convention the even stream identifiers whereas the initial | |||
answerer owns the odd stream identifiers. This ownership is | answerer owns the odd stream identifiers. This ownership is | |||
invariant for the whole lifetime of the signaling session, e.g. it | invariant for the whole lifetime of the signaling session, e.g. it | |||
does not change if the initial answerer sends a new offer to the | does not change if the initial answerer sends a new offer to the | |||
initial offerer.' with 'If an SDP offer/answer exchange (could be | initial offerer.' with 'If an SDP offer/answer exchange (could be | |||
skipping to change at page 34, line 38 ¶ | skipping to change at page 34, line 38 ¶ | |||
SDP offer. Note that the typical parser normally ignores unknown | SDP offer. Note that the typical parser normally ignores unknown | |||
SDP attributes, which includes data channel related attributes." | SDP attributes, which includes data channel related attributes." | |||
o In Section 6.3 the second sentence of the third SDP answerer | o In Section 6.3 the second sentence of the third SDP answerer | |||
action was "Note that the browser is asked to create data channels | action was "Note that the browser is asked to create data channels | |||
with stream identifiers not "owned" by the agent.". Replacement | with stream identifiers not "owned" by the agent.". Replacement | |||
of this sentence with "Note that the agent is asked to create data | of this sentence with "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 In Section 6.6 the third paragraph began with "A data channel can | o In Section 6.6.1 the third paragraph began with "A data channel | |||
be closed by sending a new SDP offer which excludes the dcmap and | can be closed by sending a new SDP offer which excludes the dcmap | |||
dcsa attribute lines for the data channel. The port value for the | and dcsa attribute lines for the data channel. The port value for | |||
m line SHOULD NOT be changed (e.g., to zero) when closing a data | the m line SHOULD NOT be changed (e.g., to zero) when closing a | |||
channel (unless all data channels are being closed and the SCTP | data channel (unless all data channels are being closed and the | |||
association is no longer needed), since this would close the SCTP | SCTP association is no longer needed), since this would close the | |||
association and impact all of the data channels. If the answerer | SCTP association and impact all of the data channels. If the | |||
accepts the SDP offer then it MUST also exclude the corresponding | answerer accepts the SDP offer then it MUST also exclude the | |||
attribute lines in the answer. ..." Replacement of this part with | corresponding attribute lines in the answer. ..." Replacement of | |||
"The intention to close a data channel can be signaled by sending | this part with "The intention to close a data channel can be | |||
a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" | signaled by sending a new SDP offer which excludes the "a=dcmap:" | |||
attribute lines for the data channel. The port value for the "m" | and "a=dcsa:" attribute lines for the data channel. The port | |||
line SHOULD NOT be changed (e.g., to zero) when closing a data | value for the "m" line SHOULD NOT be changed (e.g., to zero) when | |||
channel (unless all data channels are being closed and the SCTP | closing a data channel (unless all data channels are being closed | |||
association is no longer needed), since this would close the SCTP | and the SCTP association is no longer needed), since this would | |||
association and impact all of the data channels. If the answerer | close the SCTP association and impact all of the data channels. | |||
accepts the SDP offer then it MUST close those data channels whose | If the answerer accepts the SDP offer then it MUST close those | |||
"a=dcmap:" and "a=dcsa:" attribute lines were excluded from the | data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were | |||
received SDP offer, unless those data channels were already | excluded from the received SDP offer, unless those data channels | |||
closed, and it MUST also exclude the corresponding attribute lines | were already closed, and it MUST also exclude the corresponding | |||
in the answer." | attribute lines in the answer." | |||
o In Section 6.6 the hanging text after the third paragraph was | o In Section 6.6.1 the hanging text after the third paragraph was | |||
"This delayed close is to handle cases where a successful SDP | "This delayed close is to handle cases where a successful SDP | |||
answer is not received, in which case the state of session should | answer is not received, in which case the state of session should | |||
be kept per the last successful SDP offer/answer." Replacement of | be kept per the last successful SDP offer/answer." Replacement of | |||
this sentence with "This delayed closure is RECOMMENDED in order | this sentence with "This delayed closure is RECOMMENDED in order | |||
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 contained already procedural descriptions related to | |||
data channel reliability negotiation. Creation of new Section 6.2 | data channel reliability negotiation. Creation of new Section 6.2 | |||
and moval of reliability negotiation related text to this new | and moval of reliability negotiation related text to this new | |||
section. | section. | |||
11.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' | 11.16. 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. | |||
o Clarification of the semantic if the "max-retr" parameter is not | o Clarification of the semantic if the "max-retr" parameter is not | |||
present in an a=dcmap attribute line. In section "max-retr | present in an a=dcmap attribute line. In section "max-retr | |||
skipping to change at page 37, line 24 ¶ | skipping to change at page 37, line 24 ¶ | |||
[I-D.ietf-mmusic-sctp-sdp] | [I-D.ietf-mmusic-sctp-sdp] | |||
Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, | Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, | |||
"Session Description Protocol (SDP) Offer/Answer | "Session Description Protocol (SDP) Offer/Answer | |||
Procedures For Stream Control Transmission Protocol (SCTP) | Procedures For Stream Control Transmission Protocol (SCTP) | |||
over Datagram Transport Layer Security (DTLS) Transport.", | over Datagram Transport Layer Security (DTLS) Transport.", | |||
draft-ietf-mmusic-sctp-sdp-26 (work in progress), April | draft-ietf-mmusic-sctp-sdp-26 (work in progress), April | |||
2017. | 2017. | |||
[I-D.ietf-mmusic-sdp-mux-attributes] | [I-D.ietf-mmusic-sdp-mux-attributes] | |||
Nandakumar, S., "A Framework for SDP Attributes when | Nandakumar, S., "A Framework for SDP Attributes when | |||
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 | Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 | |||
(work in progress), December 2016. | (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. | |||
[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>. | |||
skipping to change at page 38, line 20 ¶ | skipping to change at page 38, line 20 ¶ | |||
[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., | |||
and J. Marcon, "MSRP over Data Channels", draft-ietf- | Marcon, J., and J. Recio, "MSRP over Data Channels", | |||
mmusic-msrp-usage-data-channel-07 (work in progress), | draft-ietf-mmusic-msrp-usage-data-channel-08 (work in | |||
September 2017. | progress), March 2018. | |||
[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. | |||
[IANA-SDP-Parameters] | [IANA-SDP-Parameters] | |||
"Session Description Protocol (SDP) Parameters", Internet | "Session Description Protocol (SDP) Parameters", Internet | |||
Assigned Numbers Authority Protocol Assignments Session | Assigned Numbers Authority Protocol Assignments Session | |||
Description Protocol (SDP) Parameters, | Description Protocol (SDP) Parameters, | |||
skipping to change at page 42, line 25 ¶ | skipping to change at page 42, line 25 ¶ | |||
Email: Juergen.S-B.ietf@email.de | Email: Juergen.S-B.ietf@email.de | |||
Richard Ejzak | Richard Ejzak | |||
Unaffiliated | Unaffiliated | |||
Email: richard.ejzak@gmail.com | Email: richard.ejzak@gmail.com | |||
Jerome Marcon | Jerome Marcon | |||
Unaffiliated | Unaffiliated | |||
Email: jeromee.marcon@free.fr | ||||
Roni Even (editor) | Roni Even (editor) | |||
Huawei | Huawei | |||
Email: roni.even@huawei.com | Email: roni.even@huawei.com | |||
End of changes. 86 change blocks. | ||||
185 lines changed or deleted | 197 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |