draft-ietf-mmusic-data-channel-sdpneg-22.txt   draft-ietf-mmusic-data-channel-sdpneg-23.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: May 23, 2019 Nokia Expires: July 21, 2019 Nokia
J. Stoetzer-Bradler J. Stoetzer-Bradler
R. Ejzak R. Ejzak
J. Marcon J. Marcon
Unaffiliated Unaffiliated
R. Even, Ed. R. Even, Ed.
Huawei Huawei
November 19, 2018 January 17, 2019
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-22 draft-ietf-mmusic-data-channel-sdpneg-23
Abstract Abstract
The Real-Time Communication in WEB-browsers (RTCWeb) working group is Data channel setup can be done using either the in- band Data Channel
charged to provide protocols to support direct interactive rich Establishment Protocol (DCEP) or using some out-of- band non-DCEP
communications using audio, video, and data between two peers' web- protocol. This document specifies how the SDP (Session Description
browsers. For the support of data communication, the RTCWeb working Protocol) offer/answer exchange can be used to achieve an out-of-band
group has in particular defined the concept of bi-directional data non-DCEP negotiation for establishing a data channel.
channels over SCTP (Stream Control Transmission Protocol), where each
data channel might be used to transport other protocols, called
subprotocols. Data channel setup can be done using either the in-
band Data Channel Establishment Protocol (DCEP) or using some out-of-
band non-DCEP protocol. This document specifies how the SDP (Session
Description Protocol) offer/answer exchange can be used to achieve
such an out-of-band non-DCEP negotiation. Even though data channels
are designed for RTCWeb use initially, they may be used by other
protocols like, but not limited to, the CLUE protocol (which is
defined by the IETF "ControLling mUltiple streams for tElepresence"
working group). This document is intended to be used wherever data
channels are used.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 23, 2019. This Internet-Draft will expire on July 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 9 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . 10 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 9
5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10
5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . 14
6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15
skipping to change at page 4, line 16 skipping to change at page 4, line 7
Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 Using DCEP . . . . . . . . . . . . . . . . . . . . . 36
A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 36 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 36
A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 37
A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37
A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 37
A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The RTCWeb working group has defined the concept of bi-directional The concept of establishing a bi-directional data channels running on
data channels running on top of the Stream Control Transmission top of the Stream Control Transmission Protocol (SCTP) is in
Protocol (SCTP) [I-D.ietf-rtcweb-data-channel]. RTCWeb allows [I-D.ietf-rtcweb-data-channel] allowing applications to use data
applications to use data channels. RTCWeb defines an in-band Data channels. An in-band Data Channel Establishment Protocol (DCEP) is
Channel Establishment Protocol (DCEP) in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-
[I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band band protocols may be used for establishing data channels. Each data
protocols may be used for establishing data channels. Each data
channel consists of paired SCTP streams sharing the same SCTP Stream channel consists of paired SCTP streams sharing the same SCTP Stream
Identifier. Data channels are created by endpoint applications using Identifier. Data channels are created by endpoint applications using
the WebRTC API (Application Programming Interface), or other prtocols the WebRTC API (Application Programming Interface), or other prtocols
like CLUE [I-D.ietf-clue-datachannel]. The protocols can be signaled like CLUE [I-D.ietf-clue-datachannel]. The protocols can be signaled
by the data channel "subprotocol" parameter, conceptually similar to by the data channel "subprotocol" parameter, conceptually similar to
the WebSocket [RFC5234] "subprotocol". However, apart from the the WebSocket [RFC5234] "subprotocol". However, apart from the
"subprotocol" value transmitted to the peer, RTCWeb leaves it open "subprotocol" value transmitted to the peer, an endpoint applications
how endpoint applications can agree on how to instantiate a given can agree on how to instantiate a given subprotocol on a data
subprotocol on a data channel, and whether it is signaled in-band channel, and whether it is signaled in-band using DCEP or out-of-band
using DCEP or out-of-band using a non-DCEP protocol (or both). In using a non-DCEP protocol (or both).
particular, the SDP offer generated by the RTCweb data channel stack
includes no channel-specific information.
This document defines SDP offer/answer [RFC3264] procedures that This document defines SDP offer/answer [RFC3264] procedures that
enable out-of-band negotiation for establishing data channels for enable out-of-band negotiation for establishing data channels for
transport of well-defined subprotocols. These procedures are based transport of well-defined subprotocols. These procedures are based
on generic SDP offer/answer negotiation rules for SCTP based media on generic SDP offer/answer negotiation rules for SCTP based media
transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m"
line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP.
This document makes use of MSRP (Message Session Relay Protocol) This document uses MSRP (Message Session Relay Protocol) [RFC4975]
[RFC4975] and BFCP (Binary Floor Control Protocol) [RFC4582] in many and BFCP (Binary Floor Control Protocol) [RFC4582] in many of the
of the examples. It does not provide a complete specification of how examples. It does not provide a complete specification of how to
to negotiate the use of a data channel to transport MSRP. Procedures negotiate the use of a data channel to transport MSRP. Procedures
specific to each subprotocol would have to be documented elsewhere. specific to each subprotocol would have to be documented elsewhere.
For MSRP they are documented in For MSRP they are documented in
[I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some
examples is only to show how the generic procedures described herein examples is only to show how the generic procedures described herein
might apply to a specific subprotocol. might apply to a specific subprotocol.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 10, line 45 skipping to change at page 10, line 32
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.
The detailed offer/answer procedures for the dcsa attribute are
dependent on the associated sub-protocol. A sub-protocol
specification MUST define the offer/answer procedures for the dsca
attribute (if applicable) associated with the sub-protocol, if the
sub-protocol has defined offer/answer procedures when used outside of
dcsa. If no offer/answer procedures exist for the sub-protocol when
used outside of the dcsa attribute, no specification is required for
use with dcsa.
5.2.1. DCSA Syntax 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
skipping to change at page 18, line 48 skipping to change at page 18, line 48
accepts the entire offer. As a result the offerer closes the earlier accepts the entire offer. As a result the offerer closes the earlier
negotiated MSRP related data channel and both offerer and answerer negotiated MSRP related data channel and both offerer and answerer
may start using new the MSRP related data channel. may start using new the MSRP related data channel.
8. Security Considerations 8. Security Considerations
This document specifies new SDP attributes used in the negotiation of This document specifies new SDP attributes used in the negotiation of
the DATA channel parameters. the DATA channel parameters.
These parameter are negotiated as part of opening a SCTP channel over These parameter are negotiated as part of opening a SCTP channel over
DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. This document do DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol
not add any security considerations to the ones specified in may come with it's own security considerations that need to be
[I-D.ietf-mmusic-sctp-sdp] documented as part of the subprotocol definition. Otherwise this
document do not add any security considerations to the ones specified
in [I-D.ietf-mmusic-sctp-sdp]
Error cases like the use of unknown parameter values or violation the Error cases like the use of unknown parameter values or violation the
odd/even rule must be handled by closing the corresponding Data odd/even rule must be handled by closing the corresponding Data
Channel. Channel.
9. IANA Considerations 9. IANA Considerations
9.1. Subprotocol Identifiers 9.1. Subprotocol Identifiers
Registration of new subprotocol identifiers is performed using the Registration of new subprotocol identifiers is performed using the
existing IANA "WebSocket Subprotocol Name Registry" table. existing IANA "WebSocket Subprotocol Name Registry" table.
skipping to change at page 20, line 48 skipping to change at page 20, line 48
| 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 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 only defined for use at the
usage level only SHALL use the dcsa usage level when registering the dcsa usage level, 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.2.1), then a new dcsa usage level subprotocol specific way (Section 5.2.1), then a new dcsa usage level
MUST be defined for the existing media attribute. Where the SDP MUST be defined for the existing media attribute. Where the SDP
attribute is applicable to a particular subprotocol/s this SHALL also attribute is applicable to a particular subprotocol/s this SHALL also
be registered by indicating the applicable subprotocol identifiers be registered by indicating the applicable subprotocol 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) |
skipping to change at page 34, line 14 skipping to change at page 34, line 14
and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP
association on top of the DTLS connection. association on top of the DTLS connection.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-mmusic-rfc4566bis] [I-D.ietf-mmusic-rfc4566bis]
Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", draft-ietf-mmusic- Session Description Protocol", draft-ietf-mmusic-
rfc4566bis-30 (work in progress), July 2018. rfc4566bis-32 (work in progress), December 2018.
[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]
 End of changes. 16 change blocks. 
50 lines changed or deleted 46 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/