draft-ietf-mmusic-data-channel-sdpneg-18.txt   draft-ietf-mmusic-data-channel-sdpneg-19.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: November 2, 2018 Nokia Expires: December 2, 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
May 1, 2018 May 31, 2018
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-18 draft-ietf-mmusic-data-channel-sdpneg-19
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 November 2, 2018. This Internet-Draft will expire on December 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6
5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 10 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 9
5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10
5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10
5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . 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 the Initial Offer for A Data Channel . . . . . 13
6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14
6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 14
6.6. Subsequent Offers . . . . . . . . . . . . . . . . . . . . 16 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15
6.6.1. Adding a Data Channel . . . . . . . . . . . . . . . . 16 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 15
6.6.2. Closing a Data Channel . . . . . . . . . . . . . . . 16
6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 17 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 15
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 19
9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 21 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19
9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 21 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 22 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 20
9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 22 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Changes against 'draft-ietf-mmusic-data-channel- 11.1. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. Changes against 'draft-ietf-mmusic-data-channel- 11.2. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 21
11.3. Changes against 'draft-ietf-mmusic-data-channel- 11.3. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 21
11.4. Changes against 'draft-ietf-mmusic-data-channel- 11.4. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 23 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 21
11.5. Changes against 'draft-ietf-mmusic-data-channel- 11.5. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 24 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22
11.6. Changes against 'draft-ietf-mmusic-data-channel- 11.6. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 24 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22
11.7. Changes against 'draft-ietf-mmusic-data-channel- 11.7. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 25 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23
11.8. Changes against 'draft-ietf-mmusic-data-channel- 11.8. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 25 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 23
11.9. Changes against 'draft-ietf-mmusic-data-channel- 11.9. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 25 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 23
11.10. Changes against 'draft-ietf-mmusic-data-channel- 11.10. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 25 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 23
11.11. Changes against 'draft-ietf-mmusic-data-channel- 11.11. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 26 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 24
11.12. Changes against 'draft-ietf-mmusic-data-channel- 11.12. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 27 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 25
11.13. Changes against 'draft-ietf-mmusic-data-channel- 11.13. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 26
11.14. Changes against 'draft-ietf-mmusic-data-channel- 11.14. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 29 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 27
11.15. Changes against 'draft-ietf-mmusic-data-channel- 11.15. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 31 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 29
11.16. Changes against 'draft-ejzak-mmusic-data-channel- 11.16. Changes against 'draft-ejzak-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 34 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 32
11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 35 11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 33
11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 35 11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 36 12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Generic Data Channel Negotiation Aspects When Not Appendix A. Generic Data Channel Negotiation Aspects When Not
Using DCEP . . . . . . . . . . . . . . . . . . . . . 38 Using DCEP . . . . . . . . . . . . . . . . . . . . . 36
A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 39 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37
A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 39 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37
A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 39 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 39 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37
A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 40 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The RTCWeb working group has defined the concept of bi-directional The RTCWeb working group has defined the concept of bi-directional
data channels running on top of the Stream Control Transmission data channels running on top of the Stream Control Transmission
Protocol (SCTP) [I-D.ietf-rtcweb-data-channel]. RTCWeb allows Protocol (SCTP) [I-D.ietf-rtcweb-data-channel]. RTCWeb allows
applications to use data channels. RTCWeb defines an in-band Data applications to use data channels. RTCWeb defines an in-band Data
Channel Establishment Protocol (DCEP) Channel Establishment Protocol (DCEP)
[I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band
protocols may be used for establishing data channels. Each data protocols may be used for establishing data channels. Each data
skipping to change at page 12, line 34 skipping to change at page 12, line 30
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
multiplexing rules for the "a=dcsa:" attribute need to be defined as multiplexing rules for the "a=dcsa:" attribute need to be defined as
well, for instance in an extension of this SDP based data channel well, for instance in an extension of this SDP based data channel
negotiation specification. negotiation specification.
6. SDP Offer/Answer Procedures 6. SDP Offer/Answer Procedures
6.1. Managing Stream Identifiers This section defines how data channels can be negotiated using the
SDP offer/answer mechanism. The procedures apply for a given data
channel.
If a SDP offer/answer exchange (could be the initial or a subsequent The generic offer/answer procedures for negotiating the SCTP
one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media association used to realize are defined in
description being accepted, and if this SDP offer/answer exchange [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data
results in the establishment of a new SCTP association, then the SDP channel specific procedures.
offerer owns the even SCTP stream ids of this new SCTP association
and the answerer owns the odd SCTP stream identifiers. If this "m"
line is removed from the signaling session (its port number set to
zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/
SCTP based "m" line is renegotiated later on, then the even and odd
SCTP stream identifier ownership is re-determined as described above.
This document allows simultaneous use of SDP offer/answer and DCEP "Initial offer" refers to the offer in which a data channel is
negotiation. However, an SCTP stream MUST NOT be referenced in a opened. It can be the initial offer, or a subsequent offer, of the
"a=dcmap:" or "a=dcsa:" attribute of an SDP offer/answer exchange if associated SDP session.
the associated SCTP stream has already been negotiated via DCEP.
Stream ids that are not currently used in SDP offer/answer can be
used for DCEP negotiation. Stream id allocation per SDP offer/answer
negotiation may not align with DTLS role based allocation. This
could cause glare conditions when one side tries to do SDP offer/
answer negotiation on a stream id while the other end tries to open a
data channel on the same stream id using DCEP negotiation. To avoid
these glare conditions this document recommends that the data channel
stack user always selects stream ids per the above described SDP
offer/answer rule even when DCEP negotiation is used. To avoid glare
conditions, it is possible to come up with a different stream id
allocation scheme, but such schemes are outside the scope of this
document.
6.2. Negotiating Data Channel Parameters 6.1. Managing Stream Identifiers
Conveying a reliable data channel is achieved by including neither As described in [I-D.ietf-rtcweb-data-protocol], in order to avoid
'max-retr' nor 'max-time' in corresponding SDP offer's or answer's SCTP Stream identifier collisions, the endpoint acting as DTLS client
"a=dcmap:" attribute line. Conveying a partially reliable data (for the SCTP association used to realize data channels) will use
channel is achieved by including only one of 'max-retr' or 'max- even identifier values, and the endpoint acting as DTLS server will
time'. By definition max-retr and max-time are mutually exclusive, use odd identifier values. Those rules also apply when SCTP streams
so at most one of them MAY be present in the "a=dcmap:" attribute for data channels are negotiated using the offer/answer mechanism.
line. If a SDP offer contains both of these parameters then the
receiver of such an SDP offer MUST reject the SDP offer. If a SDP
answer contains both of these parameters then the offerer MUST treat
the associated SDP offer/answer failed and take appropriate recovery
actions. These recovery options are outside the scope of this
document.
The SDP answer SHALL echo the same subprotocol, max-retr, max-time, SCTP stream identifiers associated with data channels that have been
ordered parameters, if those were present in the offer, and MAY negotiated using DCEP MUST NOT be included in SDP offers and answers.
include a label parameter. They MAY appear in any order, which could
be different from the SDP offer, in the SDP answer.
When sending a subsequent offer or an answer, and for as long as the 6.2. Negotiating Data Channel Parameters
data channel is still open, the sender MUST replicate the same
information.
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 SDP media description in the following manner, where mapped to the dcmap SDP media description in the following manner
"ordered=true" is the default and may be omitted: where "ordered=true" is the default and may be omitted:
DATA_CHANNEL_RELIABLE DATA_CHANNEL_RELIABLE
ordered=true ordered=true
DATA_CHANNEL_RELIABLE_UNORDERED DATA_CHANNEL_RELIABLE_UNORDERED
ordered=false ordered=false
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
ordered=true;max-retr=<number of retransmissions> ordered=true;max-retr=<number of retransmissions>
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 By definition max-retr and max-time are mutually exclusive, so at
most one of them MAY be present in the "a=dcmap:" attribute line. If
The agent that intends to send an SDP offer to create data channels a SDP offer contains both of these parameters then the receiver of
through SDP offer/answer negotiation performs the following: such an SDP offer MUST reject the SDP offer. If a SDP answer
contains both of these parameters then the offerer MUST treat the
o Creates data channels using stream identifiers from the owned set associated SDP offer/answer failed.
(see Section 6.1). Note that the UDP/DTLS/SCTP association may
have been negotiated previously.
o Determines the list of stream identifiers assigned to data The SDP answer SHALL echo the same subprotocol, max-retr, max-time,
channels opened through SDP offer/answer negotiation. and ordered parameters, form the offer, and MAY include a label
parameter. They MAY appear in any order, which could be different
from the SDP offer, in the SDP answer.
o Generates the SDP offer with the "a=dcmap:" and "a=dcsa:" When sending a subsequent offer or an answer, and for as long as the
attributes needed, if any, for each SDP offer/answer negotiated data channel is still open, the sender MUST replicate the same
data channel, as described in Section 5 and in Section 6.2. information.
o The "a=dcsa" attributes to the SDP offer SHOULD have the 6.3. Generating the Initial Offer for A Data Channel
subprotocol parameters to the "a=dcmap" attribute with a non-empty
subprotocol identifier.
6.4. Generating SDP Answer When an offerer sends an initial offer, in order to negotiate an SCTP
stream for a data channel, the offerer:
The peer receiving such an SDP offer performs the following: o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2)
associated with the data channel in the "m=" section representing
the SCTP association used to realize the data channel; and
o Parses and applies the SDP offer, taking into account the o MAY include one or more SDP dcsa attributes (Section 6.2)
considerations discussed in Section 6.7. associated with the data channel. The value of the stream-id part
of each attribute SHALL match the dcmap-stream-id value of the
dcmap attribute.
o Analyzes the channel parameters and subprotocol attributes to 6.4. Generating SDP Answer
determine whether to accept each offered data channel.
o For accepted data channels, the agent MUST create peer instances When an answerer receives an offer that includes an "m=" section for
for the data channels using the SCTP stream identifiers and an SCTP association, that describes an SCTP stream for a data
channel parameters contained in the SDP offer. channel, if the answerer accepts the data channel it:
o Generates an SDP answer. o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2)
associated with the data channel in the "m=" section representing
the SCTP association used to realize the data channel. The value
of the dcmap-stream-id value of the dcmap attribute SHALL be
identical to the value used for the data channel in the offer; and
o Completes the SDP answer with the "a=dcmap:" and optional o MAY include one or more SDP dcsa attributes (Section 6.2)
"a=dcsa:" attributes needed for each SDP offer/answer negotiated associated with the data channel.
data channel, as described in Section 5 and in Section 6.2. The
number of "a=dcsa:" attributes in the SDP answer does not have to
match the number of "a=dcsa:" attributes in the SDP offer.
6.5. Offerer Processing of the SDP Answer 6.5. Offerer Processing of the SDP Answer
An offerer receiving a SDP answer performs the following: An offerer receiving a SDP answer performs the following:
o Closes any created data channels as described in Section 6.6.2 for o SHALL closes any created data channels as described in
which the expected "a=dcmap:" and "a=dcsa:" attributes are not Section 6.6.1 for which the expected "a=dcmap:" attributes are not
present in the SDP answer. If the SDP answer does has no present in the SDP answer. If the SDP answer has no "a=dcmap"
"a=dcmap" attribute either the peer does not support "a=dcmap:" attribute either the peer does not support "a=dcmap:" attributes
attributes or it rejected all the data channels. In either case or it rejected all the data channels. In either case the offerer
the offerer closes all the SDP offer/answer negotiated data closes all the SDP offered data channels that were open at the
channels that were open at the time of offer. The DTLS time of offer. The DTLS association and SCTP association will
association and SCTP association will still be setup. still be setup.
o Applies the SDP answer.
Each agent application MUST wait to send data until it has Each agent application MUST wait to send data until it has
confirmation that the data channel at the peer is instantiated. For confirmation that the data channel at the peer is instantiated. For
WebRTC, this is when both data channel stacks have channel parameters WebRTC, this is when both data channel stacks have channel parameters
instantiated. This occurs: instantiated. This occurs:
o At both peers when a data channel is created without an o At both peers when a data channel is created without a previously
established SCTP association, as soon as the SCTP association is established SCTP association, as soon as the SCTP association is
successfully established. successfully established.
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 an SDP offer/ established SCTP association, as soon as it creates the negotiated
answer negotiated data channel based on information signaled in data channel based on information signaled in the SDP offer.
the SDP offer.
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 data channel for
negotiated data channel for which there is an established SCTP which there is an established SCTP association, when it receives
association, when it receives the SDP answer confirming acceptance the SDP answer confirming acceptance of the data channel or when
of the data channel or when it begins to receive data on the data it begins to receive data on the data channel from the peer,
channel from the peer, whichever occurs first. 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. Subsequent Offers 6.6. Modifying the Session
Subsequent offers should include all parameters of the existing
channels. 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. Adding a Data Channel
When an application wants to add a data channel it MUST send a new
offer adding a new a=dcmap with a new dcmap-stream-id and optionally
a=dcsa attributes.
6.6.2. Closing a Data Channel
When the application requests the closing of a data channel that was
negotiated via SDP offer/answer, the data channel stack always
performs an SCTP SSN reset [RFC6525] for this channel. The SCTP SSN
reset the Stream Sequence Number of the stream back to zero.
It is specific to the subprotocol whether this data channel will be
closed or will be re-used by a new Offer/Answer Exchange exchange.
The intention to close a data channel MUST be signaled by sending a
new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute
lines for the data channel. The offerer SHOULD NOT change the port
value for the "m" line (e.g. to zero) when closing a data channel
(unless all data channels are being closed and the SCTP association
is no longer needed), since this would close the SCTP association and
impact all of the data channels. If the answerer accepts the SDP
offer then the answerer MUST close those data channels whose
"a=dcmap:" and "a=dcsa:" attribute lines were excluded from the
received SDP offer, unless those data channels were already closed,
and the answerer MUST also exclude the corresponding attribute lines
in the answer. In addition to that, the SDP answerer MAY exclude
other data channels which were closed but not yet communicated to the
peer. So, the offerer MUST inspect the answer to see if it has to
close other data channels that are now not included in the answer.
If a new SDP offer/answer is used to close data channels then the
data channel(s) SHOULD only be closed by the answerer/offerer after a
successful SDP answer is sent/received.
This delayed closure is RECOMMENDED in order to handle cases where When an offer sends a subsequent offer, that includes information for
a successful SDP answer is not received, in which case the state a previously negotiated SCTP stream for a data channel, unless the
of the session SHOULD be kept per the last successful SDP offer/ offerer intends to close the data channel (Section 6.6.1), the
answer. offerer SHALL include the previously negotiated SDP attributes and
attribute values associated with the data channel.
If a client receives a data channel close indication (due to inband 6.6.1. Closing a Data Channel
SCTP SSN reset or some other reason) without associated SDP offer
then the client SHOULD generate an SDP offer which excludes this
closed data channel.
The application MUST also close any data channel that was negotiated In order to close a data channel the endpoint that wants to close
via SDP offer/answer, for which the stream identifiers are not listed SHALL send the SCTP SSN reset message [RFC6525], following the
in an incoming SDP offer. procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In
addition, if the closed data channel was negotiated using the offer/
answer mechanism Section 6.3, the endpoint that closed the data
channel SHALL send a subsequent offer, in which it either:
A closed data channel using local close (SCTP SSN reset), without an o removes the SDP dcmap attribute and SDP dcsa attributes associated
additional SDP offer/answer to close it, may be reused for a new data with the closed data channel. Once the endpoint receives a
channel. This MUST be done via new SDP offer/answer, describing the successful answer, the SCTP stream identifier value can later be
new subprotocol and its attributes, only after the corresponding data used for a new data channel (negotiated using DCTP or using the
channel close acknowledgment is received from the peer (i.e. SCTP offer/answer mechanism); or
SSN reset of both incoming and outgoing streams is completed). This
restriction is to avoid the race conditions between arrival of "SDP
offer which reuses stream" with "SCTP SSN reset which closes outgoing
stream" at the peer.
If the offer or the answer do not include any "a=dcmap" attributes o immediately re-uses the SCTP stream used for the closed data
all the SDP offer/answer negotiated data channels are expected to be channel for a new data channel, using the procedures in
closed now. The DTLS/SCTP association remains open for new SDP Section 6.3. The offerer SHALL use a different SDP dcmap
offer/answer or DCEP negotiation of data channels. attribute value for the data channel using the same SCTP stream.
6.7. Various SDP Offer/Answer Considerations 6.7. Various SDP Offer/Answer Considerations
SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" An SDP offer or answer has no "a=dcmap:" attributes but has
attributes. "a=dcsa:" attributes.
* This is considered an error case. In this case the receiver of * This is considered an error case. In this case the receiver of
such an SDP offer or answer SHOULD ignore the "a=dcsa:" such an SDP offer or answer SHOULD ignore the "a=dcsa:"
attributes and SHOULD process the SDP offer or answer as per attributes and SHOULD process the SDP offer or answer as per
above case 'SDP offer has no "a=dcmap:" attributes' or case above case 'SDP offer has no "a=dcmap:" attributes' or case
'SDP answer has no "a=dcmap:" attributes'. 'SDP answer has no "a=dcmap:" attributes'.
SDP offer or answer has an "a=dcsa" attribute, whose subprotocol SDP offer or answer has an "a=dcsa" attribute, whose subprotocol
attribute is unknown. attribute is unknown.
skipping to change at page 23, line 19 skipping to change at page 21, line 19
| ... | ... | | ... | ... |
| 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, Christian and Gavin Llewellyn, and to thank Flemming Andreasen, Christian
Groves, Gunnar Hellstrom, Christer Holmberg, Paul Kyzivat, Jonathan Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe
Lennox, Uwe Rauschenbach and Roman Shpount for their invaluable Rauschenbach and Roman Shpount for their invaluable comments.
comments.
Special thanks to Christer Holmberg for helping finish the document
and cleaning the SDP offer/answer section.
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 31, line 16 skipping to change at page 29, line 16
parameter with value "true" indicates that DATA chunks in the parameter with value "true" indicates that DATA chunks in the
channel MUST be dispatched to the upper layer by the receiver channel MUST be dispatched to the upper layer by the receiver
while preserving the order." with "The 'ordered' parameter with while preserving the order." with "The 'ordered' parameter with
value "true" indicates that the receiver MUST dispatch DATA chunks value "true" indicates that the receiver MUST dispatch DATA chunks
in the data channel to the upper layer while preserving the in the data channel to the upper layer while preserving the
order.". order.".
o In Section 6.3's first paragraph replacement of the one occurrence o In Section 6.3's first paragraph replacement of the one occurrence
of "must" with "..., it MUST wait until ...". of "must" with "..., it MUST wait until ...".
o In Section 6.6.2: 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 ...".
skipping to change at page 33, line 38 skipping to change at page 31, 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.2 the third paragraph began with "A data channel o In Section 6.6.1 the third paragraph began with "A data channel
can be closed by sending a new SDP offer which excludes the dcmap can be closed by sending a new SDP offer which excludes the dcmap
and dcsa attribute lines for the data channel. The port value for and dcsa attribute lines for the data channel. The port value for
the m line SHOULD NOT be changed (e.g., to zero) when closing a the m line SHOULD NOT be changed (e.g., to zero) when closing a
data channel (unless all data channels are being closed and the data channel (unless all data channels are being closed and the
SCTP association is no longer needed), since this would close the SCTP association is no longer needed), since this would close the
SCTP association and impact all of the data channels. If the SCTP association and impact all of the data channels. If the
answerer accepts the SDP offer then it MUST also exclude the answerer accepts the SDP offer then it MUST also exclude the
corresponding attribute lines in the answer. ..." Replacement of corresponding attribute lines in the answer. ..." Replacement of
this part with "The intention to close a data channel can be this part with "The intention to close a data channel can be
signaled by sending a new SDP offer which excludes the "a=dcmap:" signaled by sending a new SDP offer which excludes the "a=dcmap:"
skipping to change at page 34, line 11 skipping to change at page 32, line 11
value for the "m" line SHOULD NOT be changed (e.g., to zero) when value for the "m" line SHOULD NOT be changed (e.g., to zero) when
closing a data channel (unless all data channels are being closed closing a data channel (unless all data channels are being closed
and the SCTP association is no longer needed), since this would and the SCTP association is no longer needed), since this would
close the SCTP association and impact all of the data channels. close the SCTP association and impact all of the data channels.
If the answerer accepts the SDP offer then it MUST close those If the answerer accepts the SDP offer then it MUST close those
data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were
excluded from the received SDP offer, unless those data channels excluded from the received SDP offer, unless those data channels
were already closed, and it MUST also exclude the corresponding were already closed, and it MUST also exclude the corresponding
attribute lines in the answer." attribute lines in the answer."
o In Section 6.6.2 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 contained already procedural descriptions related to Section 5.1 contained already procedural descriptions related to
skipping to change at page 37, line 26 skipping to change at page 35, line 26
[I-D.ietf-mmusic-dtls-sdp] [I-D.ietf-mmusic-dtls-sdp]
Holmberg, C. and R. Shpount, "Session Description Protocol Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport (SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)", Layer Security (DTLS) and Transport Layer Security (TLS)",
draft-ietf-mmusic-dtls-sdp-32 (work in progress), October draft-ietf-mmusic-dtls-sdp-32 (work in progress), October
2017. 2017.
[I-D.ietf-mmusic-msrp-usage-data-channel] [I-D.ietf-mmusic-msrp-usage-data-channel]
Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
Marcon, J., and J. Recio, "MSRP over Data Channels", Marcon, J., and J. Recio, "MSRP over Data Channels",
draft-ietf-mmusic-msrp-usage-data-channel-08 (work in draft-ietf-mmusic-msrp-usage-data-channel-09 (work in
progress), March 2018. progress), May 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,
 End of changes. 61 change blocks. 
227 lines changed or deleted 159 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/