draft-ietf-mmusic-data-channel-sdpneg-25.txt   draft-ietf-mmusic-data-channel-sdpneg-26.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: September 20, 2019 Nokia Expires: October 25, 2019 Nokia
R. Ejzak R. Ejzak
J. Marcon J. Marcon
Unaffiliated Unaffiliated
R. Even, Ed. R. Even, Ed.
Huawei Huawei
March 19, 2019 April 23, 2019
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-25 draft-ietf-mmusic-data-channel-sdpneg-26
Abstract Abstract
Data channel setup can be done using either the in-band Data Channel Data channel setup can be done using either the in-band Data Channel
Establishment Protocol (DCEP) or using some out-of-band non-DCEP Establishment Protocol (DCEP) or using some out-of-band non-DCEP
protocol. This document specifies how the SDP (Session Description protocol. This document specifies how the SDP (Session Description
Protocol) offer/answer exchange can be used to achieve an out-of-band Protocol) offer/answer exchange can be used to achieve an out-of-band
non-DCEP negotiation for establishing a data channel. non-DCEP negotiation for establishing a data channel.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 20, 2019. This Internet-Draft will expire on October 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6 5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6
5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6
5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 6 5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 6
5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8 5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8
5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8 5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8
5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8
5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 8 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9
5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9
5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9
5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 9 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 9
5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 9 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10
5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10
5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11
5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12
6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 13 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 13
6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13
6.3. Generating the Initial Offer for A Data Channel . . . . . 14 6.3. Generating the Initial Offer for A Data Channel . . . . . 14
6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14
6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 14 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15
6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15
6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 16
6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 20
9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 20
9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 21
9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Changes against 'draft-ietf-mmusic-data-channel- 12.1. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 21 sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 22
12.2. Changes against 'draft-ietf-mmusic-data-channel- 12.2. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 21 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 22
12.3. Changes against 'draft-ietf-mmusic-data-channel- 12.3. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 21 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 22
12.4. Changes against 'draft-ietf-mmusic-data-channel- 12.4. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 21 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 22
12.5. Changes against 'draft-ietf-mmusic-data-channel- 12.5. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22
12.6. Changes against 'draft-ietf-mmusic-data-channel- 12.6. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22
12.7. Changes against 'draft-ietf-mmusic-data-channel- 12.7. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23
12.8. Changes against 'draft-ietf-mmusic-data-channel- 12.8. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 24
12.9. Changes against 'draft-ietf-mmusic-data-channel- 12.9. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 24
12.10. Changes against 'draft-ietf-mmusic-data-channel- 12.10. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 24
12.11. Changes against 'draft-ietf-mmusic-data-channel- 12.11. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 24 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 25
12.12. Changes against 'draft-ietf-mmusic-data-channel- 12.12. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 25 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 26
12.13. Changes against 'draft-ietf-mmusic-data-channel- 12.13. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 26 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 27
12.14. Changes against 'draft-ietf-mmusic-data-channel- 12.14. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 27 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 28
12.15. Changes against 'draft-ietf-mmusic-data-channel- 12.15. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 30
12.16. Changes against 'draft-ejzak-mmusic-data-channel- 12.16. Changes against 'draft-ejzak-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 33
12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33 12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 34
12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33 12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . 35 13.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Generic Data Channel Negotiation Aspects When Not Appendix A. Generic Data Channel Negotiation Aspects When Not
Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 Using DCEP . . . . . . . . . . . . . . . . . . . . . 36
A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37
A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 38
A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 38
A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 38
A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The concept of establishing a bi-directional data channel running on The concept of establishing a bi-directional data channel running on
top of the Stream Control Transmission Protocol (SCTP) is in top of the Stream Control Transmission Protocol (SCTP) is in
[I-D.ietf-rtcweb-data-channel] allowing applications to use data [I-D.ietf-rtcweb-data-channel] allowing applications to use data
channels. An in-band Data Channel Establishment Protocol (DCEP) is channels. An in-band Data Channel Establishment Protocol (DCEP) is
in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of- in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-
band protocols may be used for establishing data channels. Each data band protocols may be used for establishing data channels. Each data
skipping to change at page 5, line 15 skipping to change at page 5, line 15
Data channel stack: An entity which, upon application request, Data channel stack: An entity which, upon application request,
runs the data channel protocol to keep track of states, sending runs the data channel protocol to keep track of states, sending
and receiving data. If the application is a browser based and receiving data. If the application is a browser based
JavaScript application then this stack resides in the browser. If JavaScript application then this stack resides in the browser. If
the application is a native application then this stack resides in the application is a native application then this stack resides in
the application and is accessible via some sort of APIs. the application and is accessible via some sort of APIs.
Data channel properties: Fixed properties assigned to a data Data channel properties: Fixed properties assigned to a data
channel at the time of its creation. Some of these properties channel at the time of its creation. Some of these properties
determine the way the data channel stack transmits data on this determine the way the data channel stack transmits data on this
channel (e.g., stream identifier, reliability, order of channel (e.g., stream identifier, reliability, order of delivery,
delivery...). etc.).
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. SDP offer/answer exchange can be used as specified in channel. SDP offer/answer exchange can be used as specified in
this document to negotiate the establishment of data channels, this document to negotiate the establishment of data channels,
corresponding data channel properties, associated data channel corresponding data channel properties, associated data channel
subprotocols and data channel subprotocol properties. In this subprotocols and data channel subprotocol properties. In this
case the data channel subprotocols may be identified by the values case the data channel subprotocols may be identified by the values
of the "subprotocol" parameters of the SDP "a=dcmap" attribute as of the "subprotocol" parameters of the SDP "a=dcmap" attribute as
skipping to change at page 8, line 6 skipping to change at page 8, line 6
a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512 a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512
a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128
a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000
Note: The last example (a=dcmap:4) shows a 'label' parameter value Note: The last example (a=dcmap:4) shows a 'label' parameter value
which contains one non-printable 'escaped-char' character (the which contains one non-printable 'escaped-char' character (the
tabulator character). tabulator character).
Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one
'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be
present. Both MUST NOT be present. present. Both MUST NOT be present.
5.1.2. Dcmap-stream-id Parameter 5.1.2. Dcmap-stream-id Parameter
The 'dcmap-stream-id' parameter indicates the SCTP stream identifier The 'dcmap-stream-id' parameter indicates the SCTP stream identifier
within the SCTP association used to form the data channel. within the SCTP association used to form the data channel.
5.1.3. Label Parameter 5.1.3. Label Parameter
The 'label' parameter indicates the name of the channel. It The 'label' parameter indicates the name of the channel. It
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.
In order to communicate with WEbRTC API the label attribute should:
o Serialize the WebRTC label as a UTF-8 string [RFC3629].
o Treat the UTF-8 serialization as a series of bytes
o For each byte in the serialization:
* If the byte can be expressed as a `quoted-char`, do so
* Otherwise, express the byte as an `escaped-char`.
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.4. 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].
skipping to change at page 9, line 4 skipping to change at page 9, line 15
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.5. 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 and the max-time parameter are not present, If the max-retr parameter and the max-time parameter are not present,
then reliable transmission is performed as specified in [RFC4960]. then reliable transmission is performed as specified in [RFC4960].
This parameter maps to the 'Number of RTX' parameter defined in This parameter maps to the 'Number of RTX' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. [I-D.ietf-rtcweb-data-protocol].
5.1.6. 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-retr parameter. The life-time starts when providing the user message to
parameter and the max-time parameter are not present, then reliable the protocol stack. The max-time parameter is optional. If the max-
transmission is performed as specified in [RFC4960]. This parameter retr parameter and the max-time parameter are not present, then
maps to the 'Lifetime in ms' parameter defined in reliable transmission is performed as specified in [RFC4960]. This
parameter maps to the 'Lifetime in ms' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. [I-D.ietf-rtcweb-data-protocol].
5.1.7. Ordered Parameter 5.1.7. Ordered Parameter
The 'ordered' parameter with value "true" indicates that the receiver The 'ordered' parameter with value "true" indicates that the receiver
will dispatch DATA chunks in the data channel to the upper layer will dispatch DATA chunks in the data channel to the upper layer
while preserving the order. The ordered parameter is optional and while preserving the order. The ordered parameter is optional and
takes two values: "true" for ordered and "false" for unordered takes two values: "true" for ordered and "false" for unordered
delivery with "true" as the default value. Any other value is delivery with "true" as the default value. Any other value is
ignored and default "ordered=true" is assumed. In the absence of ignored and default "ordered=true" is assumed. In the absence of
skipping to change at page 10, line 15 skipping to change at page 10, line 28
well, for instance in an extension of this SDP offer/answer based well, for instance in an extension of this SDP offer/answer based
data channel negotiation specification. data channel negotiation specification.
5.2. SDP DCSA Attribute 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 document.
Task Force) document. Subprotocol specific attributes MAY also be Subprotocol specific attributes MAY also be defined for exclusive use
defined for exclusive use with data channel transport, but MUST use with data channel transport, but MUST use the same syntax described
the same syntax described here for other subprotocol related here for other subprotocol related attributes.
attributes.
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
skipping to change at page 11, line 17 skipping to change at page 11, line 26
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
stream-id = 1*5DIGIT
attribute = <from-RFC4566> attribute = <from-RFC4566>
Example: Example:
a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp"
a=dcsa:2 accept-types:text/plain a=dcsa:2 accept-types:text/plain
Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where
the attribute definition can be found; it does not provide any the attribute definition can be found; it does not provide any
skipping to change at page 12, line 13 skipping to change at page 12, line 21
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.
SDP attributes that are only defined for use at the dcsa usage level,
SHALL use the dcsa usage level when registering the attribute. If
existing media attributes are used in a datachannel subprotocol
specific way, then a new dcsa usage level MUST be defined for the
existing media attribute. Where the SDP attribute is applicable to a
particular subprotocol/s this SHALL also be registered by indicating
the applicable subprotocol identifiers (see
/[I-D.ietf-mmusic-rfc4566bis] section-8.5) along with the dcsa usage
level.
5.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
skipping to change at page 13, line 11 skipping to change at page 13, line 25
The detailed offer/answer procedures for the dcsa attribute are The detailed offer/answer procedures for the dcsa attribute are
dependent on the associated sub-protocol see Section 5.2. dependent on the associated sub-protocol see Section 5.2.
6.1. Managing Stream Identifiers 6.1. Managing Stream Identifiers
In order to avoid SCTP Stream identifier collisions, in alignment In order to avoid SCTP Stream identifier collisions, in alignment
with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS
client (for the SCTP association used to realize data channels) MUST client (for the SCTP association used to realize data channels) MUST
use even identifier values, and the endpoint acting as DTLS server use even identifier values, and the endpoint acting as DTLS server
MUST use odd identifier values. SCTP stream identifiers associated MUST use odd identifier values.
with data channels that have been negotiated using DCEP MUST NOT be
included in SDP offers and answers.
SCTP stream identifiers associated with data channels that have been SCTP stream identifiers associated with data channels that have been
negotiated using DCEP MUST NOT be included in SDP offers and answers. negotiated using DCEP MUST NOT be included in SDP offers and answers.
6.2. Negotiating Data Channel Parameters 6.2. Negotiating Data Channel Parameters
The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are
mapped to the dcmap SDP attribute parameters in the following manner mapped to the dcmap SDP attribute parameters in the following manner
where "ordered=true" is the default and may be omitted: where "ordered=true" is the default and may be omitted:
skipping to change at page 15, line 19 skipping to change at page 15, line 43
o At the agent receiving an SDP offer for which there is an o At the agent receiving an SDP offer for which there is an
established SCTP association, as soon as it creates the negotiated established SCTP association, as soon as it creates the negotiated
data channel based on information signaled in the SDP offer. data channel based on information signaled in the SDP offer.
o At the agent sending an SDP offer to create a new data channel for o At the agent sending an SDP offer to create a new data channel for
which there is an established SCTP association, when it receives which there is an established SCTP association, when it receives
the SDP answer confirming acceptance of the data channel or when the SDP answer confirming acceptance of the data channel or when
it begins to receive data on the data channel from the peer, it begins to receive data on the data channel from the peer,
whichever occurs first. whichever occurs first.
Note: DCEP is not used, that is neither the SDP offerer nor the SDP
answerer send an in-band DCEP DATA_CHANNEL_OPEN message.
6.6. Modifying the Session 6.6. Modifying the Session
When an offer sends a subsequent offer, that includes information for When an offer sends a subsequent offer, that includes information for
a previously negotiated data channel, unless the offerer intends to a previously negotiated data channel, unless the offerer intends to
close the data channel (Section 6.6.1), the offerer SHALL include the close the data channel (Section 6.6.1), the offerer SHALL include the
previously negotiated SDP attributes and attribute values associated previously negotiated SDP attributes and attribute values associated
with the data channel. with the data channel. The answerer may reject the offer. The means
for rejecting an offer are dependent on the higher layer protocol.
The offer/answer exchange is atomic; if the answer is rejected, the
session reverts to the state prior to the offer [RFC3264].
6.6.1. Closing a Data Channel 6.6.1. Closing a Data Channel
In order to close a data channel, the endpoint that wants to close In order to close a data channel, the endpoint that wants to close
SHALL send the SCTP SSN reset message [RFC6525], following the SHALL send the SCTP SSN reset message [RFC6525], following the
procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In
addition, if the closed data channel was negotiated using the offer/ addition, if the closed data channel was negotiated using the offer/
answer mechanism Section 6.3, the endpoint that closed the data answer mechanism Section 6.3, the endpoint that closed the data
channel SHALL send a subsequent offer in which it either: channel SHALL send a subsequent offer in which it either:
skipping to change at page 16, line 32 skipping to change at page 17, line 10
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 IP6 IP6 2001:db8::3 c=IN 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 IP6 IP6 2001:db8::1 c=IN 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 example in Figure 1 the SDP answerer rejected the data channel In the example in Figure 1 the SDP answerer rejected the data channel
skipping to change at page 20, line 6 skipping to change at page 21, 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: | IESG Chairs | | Contact name: | IESG |
| Contact email: | iesg@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | dcmap | | Attribute name: | dcmap |
| Attribute syntax: | As per Section 5.1.1 | | Attribute syntax: | As per Section 5.1.1 |
| Attribute semantics: | As per Section 5.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 | | 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.9 | | Mux category: | SPECIAL. See Section 5.1.9 |
skipping to change at page 20, line 29 skipping to change at page 21, line 29
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: | IESG Chairs | | Contact name: | IESG |
| Contact email: | iesg@ietf.org | | Contact email: | iesg@ietf.org |
| Attribute name: | dcsa | | Attribute name: | dcsa |
| Attribute syntax: | As per Section 5.2.1 | | Attribute syntax: | As per Section 5.2.1 |
| Attribute semantics: | As per Section 5.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.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.2.2 | | Mux category: | SPECIAL. See Section 5.2.2 |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
9.3. New Usage Level
This document introduces a new "Data Channel Subprotocol Attribute"
(dcsa) usage level of the SDP media description to the IANA SDP att-
field registry. SDP attributes that are only defined for use at the
dcsa usage level, SHALL use the dcsa usage level when registering the
attribute. If existing media attributes are used in a datachannel
subprotocol specific way (Section 5.2.1), then a new dcsa usage level
MUST be defined for the existing media attribute. Where the SDP
attribute is applicable to a particular subprotocol/s this SHALL also
be registered by indicating the applicable subprotocol identifiers
(see Section 9.1) along with the dcsa usage level. E.g.
+-----------------------+-------------------------------------------+
| ... | ... |
| Usage level: | dcsa(msrp) |
| ... | ... |
+-----------------------+-------------------------------------------+
10. Contributors 10. Contributors
Juergen Stoetzer-Bradler co-authored this document. Juergen Stoetzer-Bradler co-authored this document.
11. Acknowledgments 11. 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, Christian and Gavin Llewellyn, and to thank Flemming Andreasen, Christian
Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe
skipping to change at page 23, line 22 skipping to change at page 23, line 50
o Addition of definition of "data channel subprotocol" to Section 3 o Addition of definition of "data channel subprotocol" to Section 3
as proposed on the MMUSIC list, https://www.ietf.org/mail- as proposed on the MMUSIC list, https://www.ietf.org/mail-
archive/web/mmusic/current/msg15827.html. archive/web/mmusic/current/msg15827.html.
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 "new-usage-level">.
12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' 12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07'
o Addition of two new paragraphs to Section 5.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
skipping to change at page 35, line 5 skipping to change at page 35, line 38
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
skipping to change at page 35, line 27 skipping to change at page 36, line 18
<https://www.rfc-editor.org/info/rfc6525>. <https://www.rfc-editor.org/info/rfc6525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-clue-datachannel] [I-D.ietf-clue-datachannel]
Holmberg, C., "CLUE Protocol data channel", draft-ietf- Holmberg, C., "CLUE Protocol data channel", draft-ietf-
clue-datachannel-15 (work in progress), August 2018. clue-datachannel-17 (work in progress), April 2019.
[I-D.ietf-mmusic-msrp-usage-data-channel] [I-D.ietf-mmusic-msrp-usage-data-channel]
Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
Marcon, J., and J. Recio, "MSRP over Data Channels", Marcon, J., and J. Recio, "MSRP over Data Channels",
draft-ietf-mmusic-msrp-usage-data-channel-09 (work in draft-ietf-mmusic-msrp-usage-data-channel-10 (work in
progress), May 2018. progress), April 2019.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582,
November 2006, <https://www.rfc-editor.org/info/rfc4582>. November 2006, <https://www.rfc-editor.org/info/rfc4582>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
"The Message Session Relay Protocol (MSRP)", RFC 4975, "The Message Session Relay Protocol (MSRP)", RFC 4975,
DOI 10.17487/RFC4975, September 2007, DOI 10.17487/RFC4975, September 2007,
<https://www.rfc-editor.org/info/rfc4975>. <https://www.rfc-editor.org/info/rfc4975>.
 End of changes. 46 change blocks. 
85 lines changed or deleted 91 lines changed or added

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