draft-ietf-mmusic-data-channel-sdpneg-17.txt   draft-ietf-mmusic-data-channel-sdpneg-18.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: October 6, 2018 Nokia Expires: November 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
April 4, 2018 May 1, 2018
SDP-based Data Channel Negotiation SDP-based Data Channel Negotiation
draft-ietf-mmusic-data-channel-sdpneg-17 draft-ietf-mmusic-data-channel-sdpneg-18
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 October 6, 2018. This Internet-Draft will expire on November 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 51 skipping to change at page 2, line 51
5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10
5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 12 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 12
6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13
6.3. Generating Initial Offer . . . . . . . . . . . . . . . . 14 6.3. Generating Initial Offer . . . . . . . . . . . . . . . . 14
6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14
6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15
6.6. Subsequent Offers . . . . . . . . . . . . . . . . . . . . 16 6.6. Subsequent Offers . . . . . . . . . . . . . . . . . . . . 16
6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 16 6.6.1. Adding a Data Channel . . . . . . . . . . . . . . . . 16
6.6.2. Closing a Data Channel . . . . . . . . . . . . . . . 16
6.7. Various SDP Offer/Answer Scenarios and Considerations . . 17 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 17
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 22 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 21
9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 22 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 21
9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 22 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 23 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 22
9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 23 9.3. New Usage Level . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Changes against 'draft-ietf-mmusic-data-channel- 11.1. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 24 sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. Changes against 'draft-ietf-mmusic-data-channel- 11.2. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 24 sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 23
11.3. Changes against 'draft-ietf-mmusic-data-channel- 11.3. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 24 sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 23
11.4. Changes against 'draft-ietf-mmusic-data-channel- 11.4. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 24 sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 23
11.5. Changes against 'draft-ietf-mmusic-data-channel- 11.5. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 25 sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 24
11.6. Changes against 'draft-ietf-mmusic-data-channel- 11.6. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 25 sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 24
11.7. Changes against 'draft-ietf-mmusic-data-channel- 11.7. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 26 sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 25
11.8. Changes against 'draft-ietf-mmusic-data-channel- 11.8. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 26 sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 25
11.9. Changes against 'draft-ietf-mmusic-data-channel- 11.9. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 26 sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 25
11.10. Changes against 'draft-ietf-mmusic-data-channel- 11.10. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 26 sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 25
11.11. Changes against 'draft-ietf-mmusic-data-channel- 11.11. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 27 sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 26
11.12. Changes against 'draft-ietf-mmusic-data-channel- 11.12. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 28 sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 27
11.13. Changes against 'draft-ietf-mmusic-data-channel- 11.13. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 29 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 28
11.14. Changes against 'draft-ietf-mmusic-data-channel- 11.14. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 30 sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 29
11.15. Changes against 'draft-ietf-mmusic-data-channel- 11.15. Changes against 'draft-ietf-mmusic-data-channel-
sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 32 sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 31
11.16. Changes against 'draft-ejzak-mmusic-data-channel- 11.16. Changes against 'draft-ejzak-mmusic-data-channel-
sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 35 sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 34
11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 36 11.17. Changes against '-01' . . . . . . . . . . . . . . . . . 35
11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 36 11.18. Changes against '-00' . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . 37 12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 38 12.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Generic Data Channel Negotiation Aspects When Not Appendix A. Generic Data Channel Negotiation Aspects When Not
Using DCEP . . . . . . . . . . . . . . . . . . . . . 39 Using DCEP . . . . . . . . . . . . . . . . . . . . . 38
A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 39 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 39
A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 40 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 39
A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 40 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 39
A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 40 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 39
A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 41 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
can be used to transport proprietary or well-defined protocols, which can be used to transport proprietary or well-defined protocols, which
in the latter case can be signaled by the data channel "subprotocol" in the latter case can be signaled by the data channel "subprotocol"
parameter, conceptually similar to the WebSocket "subprotocol". parameter, conceptually similar to the WebSocket "subprotocol".
However, apart from the "subprotocol" value transmitted to the peer, However, apart from the "subprotocol" value transmitted to the peer,
RTCWeb leaves it open how endpoint applications can agree on how to RTCWeb leaves it open how endpoint applications can agree on how to
instantiate a given subprotocol on a data channel, and whether it is instantiate a given subprotocol on a data channel, and whether it is
signaled in-band using DCEP or out-of-band using a non-DCEP protocol signaled in-band using DCEP or out-of-band using a non-DCEP protocol
(or both). In particular, the SDP offer generated by the RTCweb data (or both). In particular, the SDP offer generated by the RTCweb data
channel stack includes no channel-specific information. channel stack includes no channel-specific information.
This document defines SDP offer/answer [RFC3264] negotiation This document defines SDP offer/answer [RFC3264] procedures that
procedures to establish data channels for transport of well-defined enable out-of-band negotiation for establishing data channels for
subprotocols, to enable out-of-band negotiation. These procedures transport of well-defined subprotocols. These procedures are based
are based on generic SDP offer/answer negotiation rules for SCTP on generic SDP offer/answer negotiation rules for SCTP based media
based media transport as specified in [I-D.ietf-mmusic-sctp-sdp] for transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m"
the SDP "m" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. In line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP.
the future, data channels could be defined over other SCTP based
protocols, such as SCTP over IP. However, corresponding potential
other "m=" line proto values are not considered in this document.
This document makes use of MSRP (Message Session Relay Protocol) and This document makes use of MSRP (Message Session Relay Protocol)
BFCP (Binary Floor Control Protocol) in many of the examples. It [RFC4975] and BFCP (Binary Floor Control Protocol) [RFC4582] in many
does not provide a complete specification of how to negotiate the use of the examples. It does not provide a complete specification of how
of a data channel to transport MSRP. Procedures specific to each to negotiate the use of a data channel to transport MSRP. Procedures
subprotocol would have to be documented elsewhere. For MSRP they are specific to each subprotocol would have to be documented elsewhere.
documented in [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of For MSRP they are documented in
MSRP in some examples is only to show how the generic procedures [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some
described herein might apply to a specific subprotocol. examples is only to show how the generic procedures described herein
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
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document uses the following terms: This document uses the following terms:
skipping to change at page 6, line 25 skipping to change at page 6, line 25
4. Applicability Statement 4. Applicability Statement
The mechanism in this document only applies to the Session The mechanism in this document only applies to the Session
Description Protocol (SDP) [RFC4566], when used together with the SDP Description Protocol (SDP) [RFC4566], when used together with the SDP
offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of
scope of this document, and is thus undefined. scope of this document, and is thus undefined.
5. SDP Data Channel Attributes 5. SDP Data Channel Attributes
This sections defines new SDP media-level attributes, that can be This sections defines two new SDP media-level attributes, that can be
used together with the SDP Offer/Answer mechanism to negotiate data used together with the SDP Offer/Answer mechanism to negotiate data
channel-specific and subprotocol-specific parameters, without the channel-specific and subprotocol-specific parameters, without the
usage of DCEP [I-D.ietf-rtcweb-data-protocol]. usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute
provides for negotiation of channel-specific parameters. The second
attribute provides for negotiation of subprotocol-specific
parameters.
Note: Appendix A provides information how data channels work in Note: Appendix A provides information how data channels work in
general and especially summarizes some key aspects, which should be general and especially summarizes some key aspects, which should be
considered for the negotiation of data channels if DCEP is not used. considered for the negotiation of data channels if DCEP is not used.
Two new SDP attributes are defined to support SDP offer/answer
negotiation of data channels. The first attribute provides for
negotiation of channel-specific parameters. The second attribute
provides for negotiation of subprotocol-specific parameters.
5.1. SDP DCMAP Attribute 5.1. SDP DCMAP Attribute
This section defines a new media level attribute "a=dcmap:" that This section defines a new media level attribute "a=dcmap:" that
defines the data channel parameters for each data channel to be defines the data channel parameters for each data channel to be
negotiated. negotiated.
The intention in exchanging this attribute is to create, on two The attribute is used to create, on two peers matched data channels
peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched as pairs of oppositely directed SCTP streams having the same set of
data channels as pairs of oppositely directed SCTP streams having the attributes. It is assumed that the data channel properties
same set of attributes. It is assumed that the data channel (reliable/partially reliable, ordered/unordered) are suitable per the
properties (reliable/partially reliable, ordered/unordered) are subprotocol transport requirements.
suitable per the subprotocol transport requirements.
5.1.1. DCMAP Attribute Syntax 5.1.1. DCMAP Attribute Syntax
"a=dcmap:" is a media level attribute having the following ABNF "a=dcmap:" is a media level attribute having the following ABNF
(Augmented Backus-Naur Form, [RFC5234]) syntax. (Augmented Backus-Naur Form, [RFC5234]) syntax.
Formal Syntax: Formal Syntax:
Name: dcmap Name: dcmap
skipping to change at page 10, line 17 skipping to change at page 10, line 17
The 'priority' parameter indicates the data channel's priority The 'priority' parameter indicates the data channel's priority
relative to the priorities of other data channels, which may relative to the priorities of other data channels, which may
additionally exist over the same SCTP association. The 'priority' additionally exist over the same SCTP association. The 'priority'
parameter maps to the 'Priority' parameter defined in parameter maps to the 'Priority' parameter defined in
[I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is
optional. In the absence of this parameter "priority=256" is optional. In the absence of this parameter "priority=256" is
assumed. assumed.
5.1.9. DCMAP Multiplexing Category 5.1.9. DCMAP Multiplexing Category
Multiplexing characteristics of SDP attributes are described in The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the
[I-D.ietf-mmusic-sdp-mux-attributes]. "a=dcmap:" attribute is SPECIAL.
The multiplexing category of the "a=dcmap:" 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=dcmap:" attribute multiplexing rules are specified for the "a=dcmap:" attribute multiplexing rules are specified for the
UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions
of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of
multiple SCTP associations on top of a single DTLS association, or multiple SCTP associations on top of a single DTLS association, or
how to add multiple SCTP associations to one BUNDLE group, then how to add multiple SCTP associations to one BUNDLE group, then
multiplexing rules for the "a=dcmap:" attribute need to be defined as multiplexing rules for the "a=dcmap:" attribute need to be defined as
well, for instance in an extension of this SDP offer/answer based well, for instance in an extension of this SDP offer/answer based
skipping to change at page 14, line 29 skipping to change at page 14, line 29
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
ordered=false;max-time=<lifetime in milliseconds> ordered=false;max-time=<lifetime in milliseconds>
6.3. Generating Initial Offer 6.3. Generating Initial Offer
The agent that intends to send an SDP offer to create data channels The agent that intends to send an SDP offer to create data channels
through SDP offer/answer negotiation performs the following: through SDP offer/answer negotiation performs the following:
o Creates data channels using stream identifiers from the owned set o Creates data channels using stream identifiers from the owned set
(see Section 6.1). (see Section 6.1). Note that the UDP/DTLS/SCTP association may
have been negotiated previously.
o Determines the list of stream identifiers assigned to data o Determines the list of stream identifiers assigned to data
channels opened through SDP offer/answer negotiation. channels opened through SDP offer/answer negotiation.
o Generates the SDP offer with the "a=dcmap:" and "a=dcsa:" o Generates the SDP offer with the "a=dcmap:" and "a=dcsa:"
attributes needed, if any, for each SDP offer/answer negotiated attributes needed, if any, for each SDP offer/answer negotiated
data channel, as described in Section 5 and in Section 6.2. data channel, as described in Section 5 and in Section 6.2.
o The "a=dcsa" attributes to the SDP offer SHOULD have the o The "a=dcsa" attributes to the SDP offer SHOULD have the
subprotocol parameters to the "a=dcmap" attribute with a non-empty subprotocol parameters to the "a=dcmap" attribute with a non-empty
subprotocol identifier. subprotocol identifier.
o Sends the SDP offer.
6.4. Generating SDP Answer 6.4. Generating SDP Answer
The peer receiving such an SDP offer performs the following: The peer receiving such an SDP offer performs the following:
o Parses and applies the SDP offer, taking into account the o Parses and applies the SDP offer, taking into account the
considerations discussed in Section 6.7. considerations discussed in Section 6.7.
o Analyzes the channel parameters and subprotocol attributes to o Analyzes the channel parameters and subprotocol attributes to
determine whether to accept each offered data channel. determine whether to accept each offered data channel.
o For accepted data channels, the agent MUST create peer instances o For accepted data channels, the agent MUST create peer instances
for the data channels using the SCTP stream identifiers and for the data channels using the SCTP stream identifiers and
channel parameters contained in the SDP offer. channel parameters contained in the SDP offer.
o Generates an SDP answer. o Generates an SDP answer.
o Completes the SDP answer with the "a=dcmap:" and optional o Completes the SDP answer with the "a=dcmap:" and optional
"a=dcsa:" attributes needed for each SDP offer/answer negotiated "a=dcsa:" attributes needed for each SDP offer/answer negotiated
data channel, as described in Section 5 and in Section 6.2. 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
o Sends the SDP answer. 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.1 for o Closes any created data channels as described in Section 6.6.2 for
which the expected "a=dcmap:" and "a=dcsa:" attributes are not which the expected "a=dcmap:" and "a=dcsa:" attributes are not
present in the SDP answer. present in the SDP answer. If the SDP answer does has no
"a=dcmap" attribute either the peer does not support "a=dcmap:"
attributes or it rejected all the data channels. In either case
the offerer closes all the SDP offer/answer negotiated data
channels that were open at the time of offer. The DTLS
association and SCTP association will still be setup.
o Applies the SDP answer. o Applies the SDP answer.
Each agent application MUST wait to send data until it has Each agent application MUST wait to send data until it has
confirmation that the data channel at the peer is instantiated. For confirmation that the data channel at the peer is instantiated. For
WebRTC, this is when both data channel stacks have channel parameters WebRTC, this is when both data channel stacks have channel parameters
instantiated. This occurs: instantiated. This occurs:
o At both peers when a data channel is created without an o At both peers when a data channel is created without an
established SCTP association, as soon as the SCTP association is established SCTP association, as soon as the SCTP association is
skipping to change at page 16, line 7 skipping to change at page 16, line 10
negotiated data channel for which there is an established SCTP negotiated data channel for which there is an established SCTP
association, when it receives the SDP answer confirming acceptance association, when it receives the SDP answer confirming acceptance
of the data channel or when it begins to receive data on the data of the data channel or when it begins to receive data on the data
channel from the peer, whichever occurs first. channel from the peer, whichever occurs first.
Note: DCEP is not used, that is neither the SDP offerer nor the SDP Note: DCEP is not used, that is neither the SDP offerer nor the SDP
answerer send an in-band DCEP DATA_CHANNEL_OPEN message. answerer send an in-band DCEP DATA_CHANNEL_OPEN message.
6.6. Subsequent Offers 6.6. Subsequent Offers
When an application wants to add a data channel it will send a new Subsequent offers should include all parameters of the existing
oofer with a new a=dcmap with a new dcmap-stream-id and optionally channels. If the offer wants to remove a data channel it will remove
a=dcsa attributes. The offer should include in the offer all the attributes with the dcmap-stream-id it wants to remove, see the
parameters of the existing channesl. If the offer wants to remove a examples in the examples section Section 7.
data channel it will remove the attributes with the dcmap-stream-id
it wants to remove, see the examples in the examples section
Section 7
6.6.1. Closing a Data Channel 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 When the application requests the closing of a data channel that was
negotiated via SDP offer/answer, the data channel stack always negotiated via SDP offer/answer, the data channel stack always
performs an SCTP SSN reset for this channel. performs an SCTP SSN reset [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 closing MUST in It is specific to the subprotocol whether this data channel will be
addition be signaled to the peer via a new SDP offer/answer exchange. closed or will be re-used by a new Offer/Answer Exchange exchange.
The intention to close a data channel can be signaled by sending a 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 new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute
lines for the data channel. The offerer SHOULD NOT change the port 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 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 (unless all data channels are being closed and the SCTP association
is no longer needed), since this would close the SCTP association and is no longer needed), since this would close the SCTP association and
impact all of the data channels. If the answerer accepts the SDP impact all of the data channels. If the answerer accepts the SDP
offer then the answerer MUST close those data channels whose offer then the answerer MUST close those data channels whose
"a=dcmap:" and "a=dcsa:" attribute lines were excluded from the "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the
received SDP offer, unless those data channels were already closed, received SDP offer, unless those data channels were already closed,
and the answerer MUST also exclude the corresponding attribute lines and the answerer MUST also exclude the corresponding attribute lines
skipping to change at page 17, line 11 skipping to change at page 17, line 18
SCTP SSN reset or some other reason) without associated SDP offer SCTP SSN reset or some other reason) without associated SDP offer
then the client SHOULD generate an SDP offer which excludes this then the client SHOULD generate an SDP offer which excludes this
closed data channel. closed data channel.
The application MUST also close any data channel that was negotiated The application MUST also close any data channel that was negotiated
via SDP offer/answer, for which the stream identifiers are not listed via SDP offer/answer, for which the stream identifiers are not listed
in an incoming SDP offer. in an incoming SDP offer.
A closed data channel using local close (SCTP SSN reset), without an A closed data channel using local close (SCTP SSN reset), without an
additional SDP offer/answer to close it, may be reused for a new data additional SDP offer/answer to close it, may be reused for a new data
channel. This can only be done via new SDP offer/answer, describing channel. This MUST be done via new SDP offer/answer, describing the
the new subprotocol and its attributes, only after the corresponding new subprotocol and its attributes, only after the corresponding data
data channel close acknowledgement is received from the peer (i.e. channel close acknowledgment is received from the peer (i.e. SCTP
SCTP SSN reset of both incoming and outgoing streams is completed). SSN reset of both incoming and outgoing streams is completed). This
This restriction is to avoid the race conditions between arrival of restriction is to avoid the race conditions between arrival of "SDP
"SDP offer which reuses stream" with "SCTP SSN reset which closes offer which reuses stream" with "SCTP SSN reset which closes outgoing
outgoing stream" at the peer. stream" at the peer.
6.7. Various SDP Offer/Answer Scenarios and Considerations
SDP offer has no "a=dcmap:" attributes.
* Initial SDP offer: No data channel is negotiated yet. The DTLS
association and SCTP association is negotiated and, if agreed,
established as per [I-D.ietf-mmusic-sctp-sdp].
* Subsequent SDP offer: All the SDP offer/answer negotiated data
channels are expected to be closed now. The DTLS/SCTP
association remains open for SDP offer/answer or DCEP
negotiation of data channels.
SDP answer has no "a=dcmap:" attributes.
* Initial SDP answer: Either the peer does not support "a=dcmap:" If the offer or the answer do not include any "a=dcmap" attributes
attributes or it rejected all the data channels. In either all the SDP offer/answer negotiated data channels are expected to be
case the offerer closes all the SDP offer/answer negotiated closed now. The DTLS/SCTP association remains open for new SDP
data channels that were open at the time of initial offer. The offer/answer or DCEP negotiation of data channels.
DTLS association and SCTP association will still be setup.
* Subsequent SDP answer: All the SDP offer/answer negotiated data 6.7. Various SDP Offer/Answer Considerations
channels are expected to be closed now. The SCTP association
remains open for future SDP offer/answer or DCEP negotiation of
data channels.
SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:"
attributes. 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 has no "a=dcsa:" attributes for a data channel.
* This is allowed and indicates there are no subprotocol
parameters to convey.
SDP answer has no "a=dcsa:" attributes for a data channel.
* This is allowed and indicates there are no subprotocol
parameters to convey in the SDP answer. 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.
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.
* 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.
SDP offer or answer has an "a=dcsa" attribute, whose subprotocol SDP offer or answer has an "a=dcsa" attribute, whose subprotocol
attribute is known, but whose subprotocol attribute semantic is attribute is known, but whose subprotocol attribute semantic is
not known for the data channel transport case. not known for the data channel transport case.
skipping to change at page 32, line 16 skipping to change at page 31, 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.1: o In Section 6.6.2:
* 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 34, line 38 skipping to change at page 33, 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.1 the third paragraph began with "A data channel o In Section 6.6.2 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 35, line 11 skipping to change at page 34, 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.1 the hanging text after the third paragraph was o In Section 6.6.2 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 35, line 38 skipping to change at page 34, line 38
o Removal of note "ACTION ITEM" from section "subprotocol o Removal of note "ACTION ITEM" from section "subprotocol
parameter". As [I-D.ietf-rtcweb-data-protocol] this document parameter". As [I-D.ietf-rtcweb-data-protocol] this document
should refer to IANA's WebSocket Subprotocol Name Registry defined should refer to IANA's WebSocket Subprotocol Name Registry defined
in [RFC6455] in [RFC6455]
o In whole document, replacement of "unreliable" with "partially o In whole document, replacement of "unreliable" with "partially
reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in
[I-D.ietf-rtcweb-data-protocol] in most places. [I-D.ietf-rtcweb-data-protocol] in most places.
o Clarification of the semantic if the "max-retr" parameter is not o Clarification of the semantic if the "max-retr" parameter is not
present in an a=dcmap attribute line. In section "max-retr present in an "a=dcmap" attribute line. In section "max-retr
parameter" the sentence "The max-retr parameter is optional with parameter" the sentence "The max-retr parameter is optional with
default value unbounded" was replaced with "The max-retr parameter default value unbounded" was replaced with "The max-retr parameter
is optional. If the max-retr parameter is not present, then the is optional. If the max-retr parameter is not present, then the
maximal number of retransmissions is determined as per the generic maximal number of retransmissions is determined as per the generic
SCTP retransmission rules as specified in [RFC4960]". SCTP retransmission rules as specified in [RFC4960]".
o Clarification of the semantic if the "max-time" parameter is not o Clarification of the semantic if the "max-time" parameter is not
present in an a=dcmap attribute line. In section "max-time present in an "a=dcmap" attribute line. In section "max-time
parameter" the sentence "The max-time parameter is optional with parameter" the sentence "The max-time parameter is optional with
default value unbounded" was replaced with "The max-time parameter default value unbounded" was replaced with "The max-time parameter
is optional. If the max-time parameter is not present, then the is optional. If the max-time parameter is not present, then the
generic SCTP retransmission timing rules apply as specified in generic SCTP retransmission timing rules apply as specified in
[RFC4960]". [RFC4960]".
o In section "label parameter" the sentence "Label is a mandatory o In section "label parameter" the sentence "Label is a mandatory
parameter." was removed and following new sentences (including the parameter." was removed and following new sentences (including the
note) were added: "The 'label' parameter is optional. If it is note) were added: "The 'label' parameter is optional. If it is
not present, then its value defaults to the empty string. Note: not present, then its value defaults to the empty string. Note:
skipping to change at page 36, line 20 skipping to change at page 35, line 20
such that 'label=""' is equivalent to the 'label' parameter not such that 'label=""' is equivalent to the 'label' parameter not
being present at all. [I-D.ietf-rtcweb-data-protocol] allows the 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."
o In section "subprotocol parameter" the sentence "Subprotocol is a o In section "subprotocol parameter" the sentence "Subprotocol is a
mandatory parameter." was replaced with "'Subprotocol' is an mandatory parameter." was replaced with "'Subprotocol' is an
optional parameter. If the 'subprotocol' parameter is not optional parameter. If the 'subprotocol' parameter is not
present, then its value defaults to the empty string." present, then its value defaults to the empty string."
o In the "Examples" section, in the first two SDP offer examples in o In the "Examples" section, in the first two SDP offer examples in
the a=dcmap attribute lines 'label="BGCP"' was replaced with the "a=dcmap" attribute lines 'label="BGCP"' was replaced with
'label="BFCP"'. 'label="BFCP"'.
o In all examples, the "m" line proto value "DTLS/SCTP" was replaced o In all examples, the "m" line proto value "DTLS/SCTP" was replaced
with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were
replaced with "a=max-message-size" attribute lines, as per draft- replaced with "a=max-message-size" attribute lines, as per draft-
ietf-mmusic-sctp-sdp-12. ietf-mmusic-sctp-sdp-12.
11.17. Changes against '-01' 11.17. Changes against '-01'
o Formal syntax for dcmap and dcsa attribute lines. o Formal syntax for dcmap and dcsa attribute lines.
skipping to change at page 37, line 5 skipping to change at page 36, line 5
o Introduction of more generic terminology, e.g. "application" o Introduction of more generic terminology, e.g. "application"
instead of "browser". instead of "browser".
o Clarification of how "max-retr and max-time affect the usage of o Clarification of how "max-retr and max-time affect the usage of
unreliable and reliable WebRTC data channels. unreliable and reliable WebRTC data channels.
o Updates of examples to take into account the SDP syntax changes o Updates of examples to take into account the SDP syntax changes
introduced with draft-ietf-mmusic-sctp-sdp-07. introduced with draft-ietf-mmusic-sctp-sdp-07.
o Removal of the SCTP port number from the a=dcmap and a=dcsa o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa"
attributes as this is now contained in the a=sctp-port attribute, attributes as this is now contained in the a=sctp-port attribute,
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-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,
skipping to change at page 38, line 5 skipping to change at page 37, line 5
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[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
Transmission Protocol (SCTP) Stream Reconfiguration",
RFC 6525, DOI 10.17487/RFC6525, February 2012,
<https://www.rfc-editor.org/info/rfc6525>.
12.2. Informative References 12.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-14 (work in progress), August 2016. clue-datachannel-14 (work in progress), August 2016.
[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)",
skipping to change at page 38, line 36 skipping to change at page 37, line 41
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,
<http://www.iana.org/assignments/sdp-parameters/ <http://www.iana.org/assignments/sdp-parameters/
sdp-parameters.xhtml>. sdp-parameters.xhtml>.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582,
November 2006, <https://www.rfc-editor.org/info/rfc4582>.
[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>.
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed.,
"The Message Session Relay Protocol (MSRP)", RFC 4975,
DOI 10.17487/RFC4975, September 2007,
<https://www.rfc-editor.org/info/rfc4975>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>. <https://www.rfc-editor.org/info/rfc6455>.
[WebRtcAPI] [WebRtcAPI]
Bergkvist, A., Burnett, D., Jennings, C., and A. Bergkvist, A., Burnett, D., Jennings, C., and A.
Narayanan, "WebRTC 1.0: Real-time Communication Between Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD-webrtc-20150210, Browsers", World Wide Web Consortium WD-webrtc-20150210,
February 2015, February 2015,
<http://www.w3.org/TR/2015/WD-webrtc-20150210/>. <http://www.w3.org/TR/2015/WD-webrtc-20150210/>.
 End of changes. 55 change blocks. 
147 lines changed or deleted 130 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/