<?xmlversion="1.0" encoding="UTF-8"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"http://xml.resource.org/authoring/rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml"> <!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"> <!ENTITY RFC3758 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3758.xml"> <!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml"> <!ENTITY RFC4582 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4582.xml"> <!ENTITY RFC4975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4975.xml"> <!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml"> <!ENTITY RFC6455 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml"> <!ENTITY RFC6525 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6525.xml"> <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY DATAREQ SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-data-channel.xml"> <!ENTITY DATAPROTO SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-data-protocol.xml"> <!ENTITY SDPSCTP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sctp-sdp.xml"> <!ENTITY SDPBIS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-rfc4566bis-32.xml"> <!ENTITY SDPMUXATTR SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-mux-attributes.xml"> <!ENTITY CLUEDATA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-clue-datachannel.xml"> <!ENTITY MSRPDATA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-msrp-usage-data-channel.xml"> ]> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc iprnotified="no" ?> <?rfc strict="no" ?> <?rfc compact="yes" ?> <?rfc subcompact="no"?> <?rfc sortrefs="yes" ?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="IETF" docName="draft-ietf-mmusic-data-channel-sdpneg-28"ipr="trust200902">number="8864" consensus="true" ipr="trust200902" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.38.0 --> <front> <titleabbrev="SDP-basedabbrev="SDP-Based Data Channel Negotiation">SDP-based Data ChannelNegotiation</title>Data Channels Using the Session Description Protocol (SDP)</title> <seriesInfo name="RFC" value="8864"/> <authorinitials="K. E."initials="K." surname="Drage" fullname="Keith Drage"> <organization>Unaffiliated</organization> <address> <email>drageke@ntlworld.com</email> </address> </author> <authorinitials="M. R."initials="M." surname="Makaraju" fullname="Maridi R. Makaraju (Raju)"> <organization>Nokia</organization> <address> <postal> <street>2000 Lucent Lane</street> <city>Naperville</city> <region>Illinois</region><country>US</country><country>United States of America</country> </postal> <email> Raju.Makaraju@nokia.com</email> </address> </author> <author fullname="Richard Ejzak"initials="R.P."initials="R." surname="Ejzak"> <organization>Unaffiliated</organization> <address> <email>richard.ejzak@gmail.com</email> </address> </author> <author fullname="Jerome Marcon"initials="J.M."initials="J." surname="Marcon"> <organization>Unaffiliated</organization> <address> <email>jeromee.marcon@free.fr</email> </address> </author> <authorinitials="R. E."initials="R." surname="Even" fullname="Roni Even" role="editor"><organization>Huawei</organization><organization></organization> <address><email>roni.even@huawei.com</email><email>ron.even.tlv@gmail.com</email> </address> </author> <datemonth="May" year="2019"/> <area>ART</area> <workgroup>MMUSIC</workgroup>month="September" year="2020"/> <abstract> <t> Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) orusingsome out-of-band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. </t> </abstract> </front> <middle> <sectiontitle="Introduction"anchor="introduction"> <name>Introduction</name> <t> The concept of establishing abi-directionalbidirectional data channel running on top of the Stream Control Transmission Protocol (SCTP) is discussed in <xreftarget="I-D.ietf-rtcweb-data-channel"/>target="RFC8831"/>, allowing applications to use data channels. An in-band Data Channel Establishment Protocol (DCEP) is described in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>, howevertarget="RFC8832"/>; however, other in-band or out-of-band protocols may be used for establishing data channels. Each data channel consists of paired SCTP streams sharing the same SCTP Stream Identifier. Data channels are created by endpoint applications usingthe(1) the WebRTC API (Application ProgrammingInterface),Interface) <xref target="WebRtcAPI"/> or (2) other protocolslike CLUE(e.g., Controlling Multiple Streams for Telepresence (CLUE) <xreftarget="I-D.ietf-clue-datachannel"/>.target="RFC8850"/>). The protocols can be signaled by the data channel"subprotocol"'subprotocol' parameter, conceptually similar tothea WebSocket subprotocol as described in <xreftarget="RFC5234"/> "subprotocol".target="RFC6455"/>. However, apart from the "subprotocol" value transmitted to the peer, an endpoint application can agree on how to 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 (orboth). </t>both).</t> <t>This document definesSDPSession Description Protocol (SDP) offer/answer procedures <xref target="RFC3264"/>proceduresthat enable out-of-band negotiation for establishing data channels for transport of well-defined subprotocols. These procedures are based on generic SDP offer/answer negotiation rules forSCTP basedSCTP-based media transport as specified in <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>target="RFC8841"/> for the SDP"m""m=" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. </t> <t>This document uses MSRP(Message(the Message Session Relay Protocol) <xref target="RFC4975"/> and BFCP(Binary(the Binary Floor Control Protocol) <xref target="RFC4582"/> inmany of theseveral examples. It does not provide a complete specification of how to negotiate the use of a data channel to transport MSRP. Procedures specific to each subprotocol would have to be documented elsewhere. ForMSRPMSRP, they are documented in <xreftarget="I-D.ietf-mmusic-msrp-usage-data-channel"/> .target="MSRP-over-Data-Channels"/>. The use of MSRP in some examples is only to show how the generic procedures described herein might apply to a specific subprotocol. </t> </section><section title="Conventions"><section> <name>Conventions</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere. </t>here.</t> </section> <sectiontitle="Terminology"anchor="terminology"> <name>Terminology</name> <t>This document uses the following terms:<list style="hanging"> <t>Data channel: A</t> <dl newline="false" spacing="normal"> <dt>Data channel:</dt> <dd>A WebRTC data channel as specified in <xreftarget="I-D.ietf-rtcweb-data-channel"/>.</t> <t>Datatarget="RFC8831"/>.</dd> <dt>Data channelstack: Anstack:</dt> <dd>An entitywhich,that, upon application request, runs the data channel protocol to keep track ofstates,states as well as the sending and receiving of data. If the application is abrowser basedbrowser-based JavaScriptapplicationapplication, then this stack resides in the browser. If the application is a nativeapplicationapplication, then this stack resides in the application and is accessible via some sort ofAPIs.</t> <t>DataAPI or APIs.</dd> <dt>Data channelproperties: Fixedproperties:</dt> <dd>Fixed properties assigned to a data channel at the time of its creation. Some of these properties determine the way the data channel stack transmits data on this channel (e.g., stream identifier, reliability, order ofdelivery, etc.).</t> <t>Datadelivery).</dd> <dt>Data channelsubprotocol: Thesubprotocol:</dt> <dd>The application protocolwhichthat is transported over a single data channel. Data channel subprotocol messages are sent as data channel payload over an established data channel. An SDP offer/answer exchange can be used as specified in this document to negotiate the establishment of data channels, corresponding data channel properties, associated data channelsubprotocolssubprotocols, and data channel subprotocol properties. In thiscasecase, the data channel subprotocols may be identified by the values of the"subprotocol"'subprotocol' parameters of the SDP"a=dcmap""a=dcmap:" attribute as described in <xref target="subprotocol-parameter"/>. Within thisdocumentdocument, the term "data channel subprotocol" is often abbreviated as just "subprotocol".</t> <t>DCEP: Data</dd> <dt>DCEP:</dt> <dd>Data Channel EstablishmentProtocolProtocol, as defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.</t> <t>In-band: Transmissiontarget="RFC8832"/>.</dd> <dt>In-band:</dt> <dd>Transmission through the peer-to-peer SCTPassociation.</t> <t>Out-of-band: Transmissionassociation.</dd> <dt>Out-of-band:</dt> <dd>Transmission through the application signalingpath.</t> <t>Peer: Frompath.</dd> <dt>Peer:</dt> <dd>From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the SDP offerer, the peer is the SDP answerer. From the perspective of the SDP answerer, the peer is the SDPofferer.</t> <t>SCTPofferer.</dd> <dt>SCTP Stream Sequence Number(SSN): the(SSN):</dt> <dd>The SCTPstream sequence numberStream Sequence Number, as specified in <xreftarget="RFC4960"/>.</t> <t>Stream identifier: Thetarget="RFC4960"/>.</dd> <dt>Stream identifier:</dt> <dd>The identifier of the outbound and inbound SCTP streams composing a datachannel.</t> </list> </t>channel.</dd> </dl> </section> <sectiontitle=" Applicability Statement"anchor="appl_statement"> <name>Applicability Statement</name> <t> The mechanism described in this document only applies tothe Session Description Protocol (SDP)SDP <xreftarget="I-D.ietf-mmusic-rfc4566bis"/>target="RFC8866"/> when used together with the SDP offer/answer mechanism <xref target="RFC3264"/>. Declarative usage of SDP is out of scope for thisdocument,document and is thus undefined.</t> </section> <sectiontitle="SDPanchor="sdp_synt"> <name>SDP Data ChannelAttributes" anchor="sdp_synt">Attributes</name> <t>This section defines two new SDP media-level attributes that can be used together with the SDP Offer/Answer mechanism to negotiatedata channel-specificdata-channel-specific and subprotocol-specific parameters without the usage of DCEP <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.target="RFC8832"/>. The first attribute (<xref target="subsec-sdp-attr-for-dc-par-neg"/>) provides for negotiation of channel-specific parameters. The second attribute (<xref target="prot_att"/>) provides for negotiation of subprotocol-specific parameters.</t><t><aside><t> Note:Appendix A<xref target="generic-out-of-band-aspects"/> provides information regarding how data channels work ingeneral and especiallygeneral. In particular, it summarizes some keyaspects, whichaspects that should be considered for the negotiation of data channels if DCEP is notused. </t>used.</t> </aside> <sectiontitle="SDP DCMAP Attribute "anchor="subsec-sdp-attr-for-dc-par-neg"> <name>SDP DCMAP Attribute</name> <t>This section defines a newmedia level attribute "a=dcmap:"media-level attribute, "a=dcmap:", that defines the data channel parameters for each data channel to be negotiated. </t><t>The<t>This attribute is used to createbi-directionalbidirectional SCTP data channels having the same set of attributes. The data channel properties(reliable/partially(reliable / partially reliable, ordered/unordered) need to be suitable per the subprotocol transport requirements. </t> <sectiontitle="DCMAP Attribute Syntax"anchor="dcmap-attr-definition"> <name>DCMAP Attribute Syntax</name> <t>"a=dcmap:" is amedia levelmedia-level attribute having the following definition and ABNF (Augmented Backus-NaurForm,Form) syntax <xreftarget="RFC5234"/>) syntax. <figure align="left" title=""> <artwork align="left"><![CDATA[ Formal Syntax: Name: dcmap Value: dcmap-value Usage Level: media Charset Dependent: no Syntax:target="RFC5234"/>. </t> <table anchor="dcmap-attrib"> <name>"a=dcmap:" Attribute Definition</name> <thead> <tr> <th colspan="2" align="center">"a=dcmap:" Attribute</th> </tr> </thead> <tbody> <tr> <td>Name</td> <td>dcmap</td> </tr> <tr> <td>Value</td> <td>dcmap-value</td> </tr> <tr> <td>Usage Level</td> <td>media</td> </tr> <tr> <td>Charset Dependent</td> <td>No</td> </tr> </tbody> </table> <t>Formal syntax:</t> <sourcecode name="abnf-1" type="abnf"><![CDATA[ dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ] dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt / priority-opt ; maxretr-opt and maxtime-opt are ; mutually exclusive;dcmap-stream-id = 1*5DIGIT ordering-opt = "ordered=" ordering-value ordering-value = "true" / "false" subprotocol-opt = "subprotocol=" quoted-string label-opt = "label=" quoted-string maxretr-opt = "max-retr=" maxretr-value maxretr-value = "0" / integer ; number of retransmissions, ; less than 2^32, ; derived from 'Reliability Parameter'of ; [I-D.ietf-rtcweb-data-protocol][RFC8832] maxtime-opt = "max-time=" maxtime-value maxtime-value = "0" / integer ; milliseconds, ; less than 2^32, ; derived from 'Reliability Parameter'of ; [I-D.ietf-rtcweb-data-protocol][RFC8832] priority-opt = "priority=" priority-value priority-value = "0" / integer ; unsigned integer value indicating the priority of ; the data channel, ; less than 2^16, ; derived from 'Priority'of ; [I-D.ietf-rtcweb-data-protocol][RFC8832] quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char = SP / quoted-visible quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % escaped-char = "%" HEXDIG HEXDIG DQUOTE =<from-RFC5234><from RFC 5234> integer =<from-RFC4566> Examples:<from RFC 4566>]]></sourcecode> <t>Examples:</t> <sourcecode name="sdp-1" type="sdp"><![CDATA[ a=dcmap:0 a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 a=dcmap:4label="foo%09bar";ordered=true;max-time=15000 ]]></artwork> </figure> </t> <t> <list style="hanging"> <t>Note:label="foo%09bar";ordered=true;max-time=15000]]></sourcecode> <aside><t>Note: The last example (a=dcmap:4) shows a 'label' parameter valuewhichthat contains onenon-printablenonprintable 'escaped-char' character (the tabulatorcharacter).</t> </list> </t>character).</t></aside> <t>Within an'a=dcmap:'"a=dcmap:" attribute line's 'dcmap-opt'valuevalue, only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be present. BothMUST NOT<bcp14>MUST NOT</bcp14> be present.</t> </section> <sectiontitle="Dcmap-stream-id Parameter"anchor="dcmap-stream-id-param-definition"> <name>'dcmap-stream-id' Parameter</name> <t>The 'dcmap-stream-id' parameter indicates the SCTP stream identifier within the SCTP association used to form the data channel.</t> </section><section title="Label Parameter"><section> <name>'label' Parameter</name> <t>The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API <xref target="WebRtcAPI"/>, an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.target="RFC8832"/>. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. </t> <t>In order to communicate withWEbRTC APIthelabel attribute should: <list style="symbols"> <t>SerializeWebRTC API, the 'label' parameter should </t> <ul spacing="normal"> <li>Serialize the WebRTC label as a UTF-8 string <xreftarget="RFC3629"/>.</t> <t>Treattarget="RFC3629"/>.</li> <li>Treat the UTF-8 serialization as a series ofbytes</t>bytes.</li> <li> <t>For each byte in theserialization: <list style="symbols"> <t>Ifserialization, </t> <ul spacing="normal"> <li>If the byte can be expressed as a`quoted-char`,'quoted-char', doso</t> <t>Otherwise,so.</li> <li>Otherwise, express the byte as an`escaped-char`.</t> </list> </t> </list> </t> <t>Note:'escaped-char'.</li> </ul> </li> </ul> <aside><t>Note: The empty stringMAY<bcp14>MAY</bcp14> also be explicitly used as a 'label' value, such that 'label=""' is equivalent to the 'label' parameter not being present at all. <xreftarget="I-D.ietf-rtcweb-data-protocol"/>target="RFC8832"/> allows the DATA_CHANNEL_OPEN message's 'Label' value to be an emptystring.</t>string.</t></aside> </section> <sectiontitle="Subprotocol Parameter"anchor="subprotocol-parameter"> <name>'subprotocol' Parameter</name> <t>The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. This parameter maps to the 'Protocol' parameter defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.target="RFC8832"/>. <xref target="IANA_subproto_ids"/> specifies how values for new subprotocolparameter valuesparameters are registered. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to an empty string.</t><t><aside><t> Note: The empty stringMAY<bcp14>MAY</bcp14> also be explicitly used as a 'subprotocol' value, such that 'subprotocol=""' is equivalent to the 'subprotocol' parameter not being present at all. <xreftarget="I-D.ietf-rtcweb-data-protocol"/>target="RFC8832"/> allows the DATA_CHANNEL_OPEN message's'Subprotocol''Protocol' value to be an empty string.</t></t></aside> </section> <sectiontitle="Max-retr Parameter"anchor="max-retr-param-definition"> <name>'max-retr' Parameter</name> <t>This parameter indicates that the data channel is partially reliable. The 'max-retr' parameter indicates the maximal number of times a user message will be retransmitted. Themax-retr'max-retr' parameter is optional. If themax-retr'max-retr' parameter and themax-time'max-time' parameter are not present, then reliable transmission is performed as specified in <xref target="RFC4960"/>. This parameter maps to the 'Number of RTX' parameter defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.</t>target="RFC8832"/>.</t> </section><section title="Max-time Parameter"><section> <name>'max-time' Parameter</name> <t> This parameter indicates that the data channel is partially reliable. A user message will no longer be transmitted or retransmitted after a specifiedlife-timelifetime, given inmillisecondsmilliseconds, in the 'max-time' parameter. Thelife-timelifetime starts when providing the user message to the protocol stack. Themax-time'max-time' parameter is optional. If themax-retr'max-retr' parameter and themax-time'max-time' parameter are not present, then reliable transmission is performed as specified in <xref target="RFC4960"/>. This parameter maps to the 'Lifetime in ms' parameter defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.</t>target="RFC8832"/>.</t> </section> <sectiontitle="Ordered Parameter"anchor="ordered-param-description"> <name>'ordered' Parameter</name> <t>The 'ordered' parameter with value "true" indicates that the receiver will dispatch DATA chunks in the data channel to the upper layer while preserving the order. Theordered'ordered' parameter is optional and takes twovalues:values -- "true" for ordered delivery and "false" for unordered delivery -- with "true" as the default value. Any other value isignoredignored, and the default "ordered=true" is assumed. In the absence of thisparameterparameter, "ordered=true" is assumed. This parameter maps to the ordered or unordered data channel types as defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.</t>target="RFC8832"/>.</t> </section> <sectiontitle="Priority Parameter"anchor="priority-param-description"> <name>'priority' Parameter</name> <t>The 'priority' parameter indicates the data channel's priority relative to the priorities of other data channels, which may additionally exist over the same SCTP association. The 'priority' parameter maps to the 'Priority' parameter defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.target="RFC8832"/>. The 'priority' parameter is optional. In the absence of thisparameterparameter, "priority=256" is assumed. </t> </section> <sectiontitle="DCMAP Multiplexing Category"anchor="dcmap-mux-category"> <name>DCMAP Multiplexing Category</name> <t>The multiplexing category <xreftarget="I-D.ietf-mmusic-sdp-mux-attributes"/>target="RFC8859"/> of the "a=dcmap:" attribute is SPECIAL. </t> <t>As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>,target="RFC8841"/>, no "a=dcmap:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions of <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>target="RFC8841"/> define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLSassociation,association or how to add multiple SCTP associations to one BUNDLE group, then multiplexing rules for the "a=dcmap:" attribute need to be defined aswell,well -- forinstanceinstance, in an extension of thisSDP offer/answer based data channel negotiationspecification. </t> </section> </section><!-- subsec-sdp-attr-for-dc-par-neg --><sectiontitle="SDP DCSA Attribute"anchor="prot_att"> <name>SDP DCSA Attribute</name> <t>In the SDP media description, each data channel declarationMAY<bcp14>MAY</bcp14> also be followed by othermedia levelSDP attributes, whichare either specifically defined for or appliedapply to thesubprotocol in use.corresponding data channel and its subprotocol. Each of these attributes is represented by one new "a=dcsa:" attributeline, and it includes the contents of a media-levelline that references another SDP attributealreadydefined for use with this(sub)protocol in another IETF document. Subprotocol specificdata channel's subprotocol. Instructions for registering attributesMAY also be definedforexclusiveuse with a data channeltransport, but MUST use the same syntax described here for other subprotocol related attributes.</t>are given in <xref target="IANA-reg-data-channel-attribs"/>.</t> <t>Each SDPattribute,attribute that is related to thesubprotocol,subprotocol and that would normally be used to negotiate the subprotocol using the SDP offer/answer mechanism is replaced with an attribute of the form "a=dcsa:stream-idoriginal-attribute",original&nbhy;attribute", wheredcsa"dcsa" stands for "data channel subprotocol attribute",stream-id"stream-id" is the SCTP stream identifier assigned to this subprotocol instance, andoriginal-attribute"original-attribute" represents the contents of thesubprotocol relatedsubprotocol-related attribute to be included.</t> <t>The same syntax applies to any other SDP attribute required for negotiation of this instance of the subprotocol.</t> <t>The detailed offer/answer procedures for the dcsa attribute are dependent on the associatedsub-protocol.subprotocol. If no offer/answer procedures exist for thesub-protocolsubprotocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. The IANA (Internet Assigned Numbers Authority) registration procedures for theWebSocket"WebSocket Subprotocol NameRegistryRegistry" (<xref target="IANA_subproto_ids"/>) do not strictly require a specification of the offer/answer procedures for thesub-protocolsubprotocol when used with dcsa. If thesub-protocolsubprotocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If thesub-protocolsubprotocol has defined offer/answer procedures when used outside ofdcsa,dcsa but no specification exists for the offer/answer procedures for thesub-protocolsubprotocol when used with dcsa, implementationsSHOULD<bcp14>SHOULD</bcp14> assume the use of the default values for all otherwise-negotiable and applicablesub-protocolsubprotocol parameters. </t> <sectiontitle="DCSA Syntax"anchor="dcsa-attribute"><t> <figure align="left" title=""> <artwork align="left"><![CDATA[ Formal Syntax: Name: dcsa Value: dcsa-value Usage Level: media Charset Dependent: no Syntax:<name>DCSA Attribute Syntax</name> <t>"a=dcsa:" is a media-level attribute having the following definition and ABNF (Augmented Backus-Naur Form) syntax <xref target="RFC5234"/>. </t> <table anchor="dcsa-attrib"> <name>"a=dcsa:" Attribute Definition</name> <thead> <tr> <th colspan="2" align="center">"a=dcsa:" Attribute</th> </tr> </thead> <tbody> <tr> <td>Name</td> <td>dcsa</td> </tr> <tr> <td>Value</td> <td>dcsa-value</td> </tr> <tr> <td>Usage Level</td> <td>media</td> </tr> <tr> <td>Charset Dependent</td> <td>No</td> </tr> </tbody> </table> <t>Formal syntax:</t> <sourcecode name="abnf-2" type="abnf"><![CDATA[ dcsa-value = stream-id SP attribute stream-id = 1*5DIGIT attribute =<from-RFC4566> Example:<from RFC 4566>]]></sourcecode> <t>Example:</t> <sourcecode name="sdp-2" type="sdp"><![CDATA[ a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" a=dcsa:2accept-types:text/plain ]]></artwork> </figure> </t>accept-types:text/plain]]></sourcecode> <t>Note that the reference to <xreftarget="I-D.ietf-mmusic-rfc4566bis"/>target="RFC8866"/> defines where the attribute definition can be found; it does not provide anylimitationlimitations on support of attributes defined in other documents in accordance with this attribute definition.Note howeverNote, however, that not all SDP attributes are suitable asaan "a=dcsa:" parameter. The registry of IANA SDP parameters contains the lists ofIANA (Internet Assigned Numbers Authority) registered sessionIANA-registered session-level andmedia levelmedia-level ormedia level onlymedia-level-only SDPattributes.</t> <t>Thusattributes. </t> <t>Thus, in the example above, the original attribute line"a=accept-types:text/plain""a=accept&nbhy;types:text/plain" is represented by the attribute line "a=dcsa:2 accept-types:text/plain", which specifies that this instance of the MSRP subprotocol being transported on the SCTP association using the data channel with stream id 2 acceptsplain textplaintext files.</t> <t>As opposed to the data channel "a=dcmap:" attribute parameters, these parameters are subject to offer/answernegotiationnegotiation, following the procedures defined in thesubprotocol specificsubprotocol-specific documents.</t> <t>It is assumed that in general the usages ofsubprotocol related media levelsubprotocol-related media-level attributes are independent from the subprotocol's transport protocol. Suchtransport protocol independent subprotocol relatedtransport-protocol-independent subprotocol-related attributes are used in the same way as defined in the original subprotocol specification, also if the subprotocol is transported over a data channel and if the attribute is correspondingly embedded ina "a=dcsa"an "a=dcsa:" attribute. </t> <t>There may becases,cases where the usage of asubprotocol related media levelsubprotocol-related media-level attribute depends on the subprotocol's transport protocol. In suchcasescases, thesubprotocol relatedsubprotocol-related usage of the attribute is expected to be described for the data channel transport. Adata channel specificdata-channel-specific usage of a subprotocol attribute is expected to be specified in the same document that registers the subprotocol's identifier for data channel usage as described in <xref target="IANA_subproto_ids"/>. </t><t>SDP attributes that are only defined for use at the dcsa usage level, SHALL use the dcsa usage level when registering the attribute. If existing media attributes are used in a datachannel subprotocol specific way, then a new dcsa usage level MUST be defined for the existing media attribute. Where the SDP attribute is applicable to a particular subprotocol/s this SHALL also be registered by indicating the applicable subprotocol identifiers (see /<xref target="I-D.ietf-mmusic-rfc4566bis"/> section-8.5) along with the dcsa usage level. </t></section> <sectiontitle="DCSA Multiplexing Category"anchor="dcsa-mux-category"> <name>DCSA Multiplexing Category</name> <t>The multiplexing category of the "a=dcsa:" attribute is SPECIAL. </t> <t>As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>,target="RFC8841"/>, no "a=dcsa:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP andTCP/DTLS/SCTPTCP&wj;/DTLS&wj;/SCTP proto values. If future extensions of <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>target="RFC8841"/> define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLSassociation,association or how to add multiple SCTP associations to one BUNDLE group, then multiplexing rules for the "a=dcsa:" attribute need to be defined aswell,well -- forinstanceinstance, in an extension of thisSDP based data channel negotiationspecification. </t> </section> </section><!-- prot_att --></section><!-- sdp_sync --><sectiontitle="SDP Offer/Answer Procedures"anchor="section_procedures"> <name>SDP Offer/Answer Procedures</name> <t>This section defines how data channels can be negotiated using the SDP offer/answer mechanism. A given media description can describe multiple data channels (each represented by a separate SDP dcmap attribute) that can be created,modifiedmodified, and closed using different offer/answer exchanges. The procedures in this section apply for a given data channel. </t> <t>The generic offer/answer procedures for negotiating the SCTP association used to realize data channels are defined in <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>.target="RFC8841"/>. This section only defines thedata channel specificdata-channel-specific procedures.</t> <t>“Initial offer”"Initial offer" refers to the offer in which a data channel is opened. It can be either the initialoffer,offer or a subsequentoffer,offer of the associated SDP session.</t> <t>The detailed offer/answer procedures for the dcsa attribute are dependent on the associatedsub-protocolsubprotocol; see <xref target="prot_att"/>. </t> <sectiontitle="Managinganchor="id_mgmt"> <name>Managing StreamIdentifiers" anchor="id_mngt">Identifiers</name> <t> In order to avoid SCTP Stream identifier collisions, in alignment with <xreftarget="I-D.ietf-rtcweb-data-protocol"/>,target="RFC8832"/>, the endpoint acting as a DTLS client (for the SCTP association used to realize data channels)MUST<bcp14>MUST</bcp14> use even identifier values, and the endpoint acting as a DTLS serverMUST<bcp14>MUST</bcp14> use odd identifier values. </t> <t>SCTP stream identifiers associated with data channels that have been negotiated using DCEPMUST NOT<bcp14>MUST NOT</bcp14> be included in SDP offers and answers. </t> </section><!-- id_mngt --><sectiontitle="Negotiatinganchor="param_negotiation"> <name>Negotiating Data ChannelParameters" anchor="param_negotiation">Parameters</name> <t> The data channel types defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>target="RFC8832"/> are mapped to the dcmap SDP attribute parameters in the followingmannermanner, where "ordered=true" is the default and may be omitted: </t><t> <figure align="left" title=""> <artwork align="left"><![CDATA[<sourcecode name="data-channel-items" type="sdp"><![CDATA[ DATA_CHANNEL_RELIABLE ordered=true DATA_CHANNEL_RELIABLE_UNORDERED ordered=false DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT ordered=true;max-retr=<number of retransmissions> DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED ordered=false;max-retr=<number of retransmissions> DATA_CHANNEL_PARTIAL_RELIABLE_TIMED ordered=true;max-time=<lifetime in milliseconds> DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED ordered=false;max-time=<lifetime inmilliseconds> ]]></artwork> </figure> </t>milliseconds>]]></sourcecode> <t> Bydefinition max-retrdefinition, 'max-retr' andmax-time'max-time' are mutually exclusive, so bothMUST NOT<bcp14>MUST NOT</bcp14> be present in the "a=dcmap:" attribute line. If an SDP offer contains both of theseparametersparameters, then the receiver of such an SDP offerMUST<bcp14>MUST</bcp14> reject the SDP offer. If an SDP answer contains both of theseparametersparameters, then the offererMUST<bcp14>MUST</bcp14> treat the associated SDP offer/answer as failed. </t> </section><!-- ="Negotiating Data Channel Parameters" --><sectiontitle="Generatinganchor="opendc"> <name>Generating the Initial Offer forAa DataChannel" anchor="opendc">Channel</name> <t>When an offerer sends an initial offer, in order to negotiate an SCTP stream for a data channel, theofferer: <list style="symbols"> <t>SHALLofferer </t> <ul spacing="normal"> <li><bcp14>SHALL</bcp14> include an SDP dcmap attribute(<xref target="sdp_synt"/>(Sections <xref target="subsec-sdp-attr-for-dc-par-neg" format="counter"/> and <xreftarget="param_negotiation"/>)target="param_negotiation" format="counter"/>) associated with the data channel in the“m=”"m=" section representing the SCTP association used to realize the datachannel;channel, and</t> <t>MAY</li> <li><bcp14>MAY</bcp14> include one or more SDP dcsa attributes (<xref target="prot_att"/>) associated with the data channel. The value of thestream-id'stream-id' part of each attributeSHALL<bcp14>SHALL</bcp14> match thedcmap-stream-id'dcmap-stream-id' value of the dcmap attribute.</t> </list> </t></li> </ul> </section><section title="Generating<section> <name>Generating the SDPAnswer">Answer</name> <t>When an answerer receives an offer that includes an“m=""m=" section for an SCTP association,thatthe offer describes an SCTP stream for a data channel, if the answerer accepts the datachannel it: <list style="symbols"> <t>SHALLchannel, it </t> <ul spacing="normal"> <li><bcp14>SHALL</bcp14> include an SDP dcmap attribute(<xref target="sdp_synt"/>(Sections <xref target="subsec-sdp-attr-for-dc-par-neg" format="counter"/> and <xreftarget="param_negotiation"/>)target="param_negotiation" format="counter"/>) associated with the data channel in the "m=" section representing the SCTP association used to realize the data channel. The value of thedcmap-stream-id, max-retr'dcmap-stream-id', 'max-retr', andmax-time'max-time' values of the dcmap attributeSHALL<bcp14>SHALL</bcp14> be identical to the value used for the data channel in theoffer;offer, and</t> <t>MAY</li> <li><bcp14>MAY</bcp14> include one or more SDP dcsa attributes (<xref target="prot_att"/>) associated with the data channel.</t> </list> </t></li> </ul> </section><section title="Offerer<section> <name>Offerer Processing of the SDPAnswer">Answer</name> <t>An offerer receiving an SDP answer performs the following:<list style="symbols"> <t>SHALL</t> <ul spacing="normal"> <li>It <bcp14>SHALL</bcp14> close any created data channels as described in <xref target="close-dc"/> for which the expected "a=dcmap:" attributes are not present in the SDP answer. If the SDP answer has no"a=dcmap" attribute"a=dcmap:" attributes, either the peer does not support "a=dcmap:" attributes or it rejected all the data channels. In eithercasecase, the offerer closes all theSDP offereddata channels offered by SDP that were open at the time of the offer. The DTLS association and SCTP association will still besetup.set up. At thispointpoint, the offerer may use DCEP negotiation <xreftarget="I-D.ietf-rtcweb-data-protocol"/>target="RFC8832"/> to open datachannels</t> </list> </t>channels.</li> </ul> <t>Each agent applicationMUST<bcp14>MUST</bcp14> wait to send data until it has confirmation that the data channel at the peer is instantiated. For WebRTC, this is when both data channel stacks have channel parametersinstantiated. This occurs: <list style="symbols"> <t>Atinstantiated and occurs as follows: </t> <ul spacing="normal"> <li>At both peers when a data channel is created without a previously established SCTP association, as soon as the SCTP association is successfullyestablished.</t> <t>Atestablished.</li> <li>At the agent receiving an SDP offer for which there is an established SCTP association, as soon as it creates the negotiated data channel based on information signaled in the SDPoffer.</t> <t>Atoffer.</li> <li>At the agent sending an SDP offer to create a new data channel for which there is an established SCTP association, when it receives the SDP answer confirming acceptance of the data channel or when it begins to receive data on the data channel from the peer, whichever occursfirst.</t> </list> </t>first.</li> </ul> </section><!-- opendc --> <section title="Modifying<section> <name>Modifying theSession">Session</name> <t>When anofferofferer sends a subsequentoffer,offer that includes information for a previously negotiated data channel, unless the offerer intends to close the data channel (<xref target="close-dc"/>), the offererSHALL<bcp14>SHALL</bcp14> include the previously negotiated SDP attributes and attribute values associated with the data channel. The answerer may reject the offer. The means for rejecting an offer are dependent on thehigher layerhigher-layer protocol. The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer <xref target="RFC3264"/>. </t> <sectiontitle="Closinganchor="close-dc"> <name>Closing a DataChannel" anchor="close-dc">Channel</name> <t>In order to close a data channel, the endpoint that wants to closeSHALL sendthe data channel <bcp14>SHALL</bcp14> send an SCTP SSNresetReset message <xref target="RFC6525"/>, following theproceduresprocedure insection 6.7 of<xreftarget="I-D.ietf-rtcweb-data-channel"/>.target="RFC8831" sectionFormat="of" section="6.7"/>. In addition, if the closed data channel was negotiated using the offer/answer mechanism<xref target="opendc"/>,(<xref target="opendc"/>), the endpoint that closed the data channelSHALL<bcp14>SHALL</bcp14> send a subsequent offer in which iteither:does one of the following: </t><t> <list style="symbols"> <t> removes<ul spacing="normal"> <li>Removes the SDP dcmap attribute and SDP dcsa attributes associated with the closed data channel. Once the endpoint receives a successful answer, the SCTP stream identifier value can later be used for a new data channel (negotiated usingDCTPeither SCTP orusingthe offer/answermechanism); or</t> <t>aftermechanism), or </li> <li>After a reset has beenperformed re-usesperformed, reuses the SCTP stream used for the closed data channel for a new data channel,usingfollowing theproceduresprocedure in <xref target="opendc"/>. The offererSHALL<bcp14>SHALL</bcp14> use a different SDP dcmap attribute value for the data channel using the same SCTP stream.</t> </list> </t></li> </ul> </section><!-- Closing a Data Channel --></section> <sectiontitle="Variousanchor="various_SDP_OA_considerations"> <name>Various SDP Offer/AnswerConsiderations" anchor="various_SDP_OA_considerations"> <t> <list>Considerations</name> <t>An SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:"attributes. <list style="symbols"> <t>Thisattributes: </t> <ul spacing="normal"> <li>This is considered an error case. In thiscasecase, the receiver of such an SDP offer or answerMUST<bcp14>MUST</bcp14> discardthisthe "a=dcsa:" attributes.</t> </list> </t> <t>SDP</li> </ul> <t>An SDP offer or answer has an"a=dcsa" attribute,"a=dcsa:" attribute whose subprotocol attribute isunknown. <list style="symbols"> <t>Theunknown: </t> <ul spacing="normal"> <li>The receiver of such an SDP offer or answerSHOULD<bcp14>SHOULD</bcp14> ignore this entire"a=dcsa""a=dcsa:" attribute line.</t> </list> </t> <t>SDP</li> </ul> <t>An SDP offer or answer has an"a=dcsa" attribute,"a=dcsa:" attribute whose subprotocol attribute isknown,known but whose subprotocol attribute semantic is not known for the data channel transportcase. <list style="symbols"> <t>Thecase: </t> <ul spacing="normal"> <li>The receiver of such an SDP offer or answerSHOULD<bcp14>SHOULD</bcp14> ignore this entire"a=dcsa""a=dcsa:" attribute line.</t> </list> </t> </list> </t></li> </ul> </section><!-- various SDP offer/answer ... --></section><!-- Procedures --><sectiontitle="Examples"anchor="examples"><figure align="left" title="Example 1" anchor="example1"> <artwork align="left"><![CDATA[ SDP offer: m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::3 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:0 subprotocol="bfcp";label="bfcp" SDP answer: m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::1 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42 ]]></artwork> </figure> <t>In the example in <xref<name>Examples</name> <t><xref target="example1"/> shows an example of an SDP offer and answer where the SDP answererrejectedrejects the data channel with stream id 0 either for explicit reasons or because it does not understand the "a=dcmap:" attribute. As aresultresult, the offerer will close the data channel created with the SDP offer/answer negotiation option. The SCTP association will still besetupset up over DTLS. At thispointpoint, the offerer or the answerer may use DCEP negotiation to open data channels.</t> <figurealign="left" title="Example 2" anchor="example2"> <artwork align="left"><![CDATA[ SDP offer:anchor="example1"> <name>Example 1</name> <sourcecode name="example-1-sdp-offer" type="sdp"><![CDATA[ m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=INIP4 192.0.2.1IP6 2001:db8::3 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:0subprotocol="bfcp";label="bfcp" a=dcmap:2 subprotocol="msrp";label="msrp" a=dcsa:2 accept-types:message/cpim text/plain a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc SDP answer:subprotocol="bfcp";label="bfcp"]]></sourcecode> <sourcecode name="example-1-sdp-answer" type="sdp"><![CDATA[ m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=INIP4 192.0.2.2IP6 2001:db8::1 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FAa=tls-id:dcb3ae65cddef0532d42 a=dcmap:2 subprotocol="msrp";label="msrp" a=dcsa:2 accept-types:message/cpim text/plain a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc ]]></artwork>a=tls-id:dcb3ae65cddef0532d42]]></sourcecode> </figure><t>In the example in <xref<t><xref target="example2"/>the SDPshows an example of an SDP offer and answer where the SDP offer contains data channels for BFCP(Binary Floor Control Protocol)and MSRP subprotocols. The SDP answerrejectedrejects BFCP andacceptedaccepts MSRP. So, the offerer closes the data channel forBFCPBFCP, and both the offerer and the answerer may start using the MSRP data channel (after the SCTP association isset up).set up). The data channel with stream id 0 is free and can be used for future DCEP or SDP offer/answer negotiation.</t><t>Continuing the example in <xref target="example2"/>.</t><figurealign="left" title="Example 3" anchor="example3"> <artwork align="left"><![CDATA[ Subsequent SDP offer:anchor="example2"> <name>Example 2</name> <sourcecode name="example-2-sdp-offer" type="sdp"><![CDATA[ m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82a=dcmap:4a=dcmap:0 subprotocol="bfcp";label="bfcp" a=dcmap:2 subprotocol="msrp";label="msrp"a=dcsa:4a=dcsa:2 accept-types:message/cpim text/plaina=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc Subsequent SDP answer:a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc]]></sourcecode> <sourcecode name="example-2-sdp-answer" type="sdp"><![CDATA[ m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.2 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42a=dcmap:4a=dcmap:2 subprotocol="msrp";label="msrp"a=dcsa:4a=dcsa:2 accept-types:message/cpim text/plaina=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc ]]></artwork>a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc]]></sourcecode> </figure> <t>The example in <xref target="example3"/> is a continuation of the example in <xref target="example2"/>. The SDP offerer now removes the MSRP data channel with stream id2,2 but opens a new MSRP data channel with stream id 4. The answerer accepts the entire offer. As aresultresult, the offerer closes theearlierpreviously negotiatedMSRP relatedMSRP-related datachannelchannel, and both the offerer and the answerer may start usingnewtheMSRP relatednew MSRP-related data channel.</t> <figure anchor="example3"> <name>Example 3</name> <sourcecode name="example-3-sdp-offer" type="sdp"><![CDATA[ m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:4 subprotocol="msrp";label="msrp" a=dcsa:4 accept-types:message/cpim text/plain a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc]]></sourcecode> <sourcecode name="example-3-sdp-answer" type="sdp"><![CDATA[ m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.2 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42 a=dcmap:4 subprotocol="msrp";label="msrp" a=dcsa:4 accept-types:message/cpim text/plain a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc]]></sourcecode> </figure> </section><!-- Examples --><sectiontitle="Security Considerations"anchor="sec-cons"> <name>Security Considerations</name> <t>This document specifies new SDP attributes used in the negotiation ofthe DATAdata channel parameters. </t> <t> Theseparameterparameters are negotiated as part of openingaan SCTP channel over DTLS as specified in <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>.target="RFC8841"/>. Each subprotocol may come withit’sits own security considerations that need to be documented as part of the subprotocol definition.OtherwiseOtherwise, this document does not add any security considerations tothe onesthose specified in <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>target="RFC8841"/>. </t><t>Error<t>Such error caseslikeas the use of unknown parameter values orviolationviolations of the odd/even ruleMUST(<xref target="id_mgmt"/>) <bcp14>MUST</bcp14> be handled by closing the correspondingData Channel.</t>data channel.</t> </section> <sectiontitle="IANA Considerations"anchor="IANA"> <name>IANA Considerations</name> <sectiontitle="Subprotocol Identifiers"anchor="IANA_subproto_ids"> <name>Subprotocol Identifiers</name> <t>Registration of new subprotocol identifiers is performed using the existing IANA "WebSocket Subprotocol Name Registry" table.</t> <t>The following textshould behas been addedfollowingbelow the title of the table.</t> <t>"This table also includes subprotocol identifiers specified for usage within a WebRTC data channel."</t><t>The following reference should be<t>This document (RFC 8864) has been added toundertheheading reference: "RFC XXXX".</t>"Reference" list for the registry.</t> <t>This document assigns no new values to this table.</t> <t>A subprotocol may simultaneously be defined for data channel transport and forWebsocketWebSocket transport. In such acasecase, the "Subprotocol Definition" and "Reference" cells in the subprotocol's row of the IANA "WebSocket Subprotocol Name Registry" table should contain two entries. One entry in each of these cells should refer to theWebsocket relatedWebSocket-related subprotocol specification, and the other entry should refer to thedata channel relateddata-channel-related subprotocol specification. </t><t>NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC.</t></section><section title="New<section> <name>New SDPAttributes">Attributes</name> <sectiontitle="dcmap"anchor="IANA-reg-dcmap"><t>NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC.</t><name>dcmap</name> <t>This document defines a new SDP media-levelattribute "a=dcmap:"attribute, "a=dcmap:", as follows: </t><texttable title=""> <ttcol align="left" width="35%"/> <ttcol align="left" width="65%"/> <c>Contact name:</c> <c>IESG</c> <c>Contact email:</c> <c>iesg@ietf.org</c> <c>Attribute name:</c> <c>dcmap</c> <c>Attribute syntax:</c> <c>As<table anchor="dcmap-iana"> <name>New "a=dcmap:" Attribute</name> <thead> <tr> <th colspan="2" align="center">"a=dcmap:"</th> </tr> </thead> <tbody> <tr> <td align="left">Contact name</td> <td align="left">IESG</td> </tr> <tr> <td align="left">Contact email</td> <td align="left">iesg@ietf.org</td> </tr> <tr> <td align="left">Attribute name</td> <td align="left">dcmap</td> </tr> <tr> <td align="left">Attribute syntax</td> <td align="left">As per <xref target="dcmap-attr-definition"/></c> <c>Attribute semantics:</c> <c>As</td> </tr> <tr> <td align="left">Attribute semantics</td> <td align="left">As per <xref target="dcmap-attr-definition"/></c> <c>Usage level:</c> <c>media</c> <c>Charset dependent:</c> <c>No</c> <c>Purpose:</c> <c>Define data channel specific parameters</c> <c>Appropriate values:</c> <c>As</td> </tr> <tr> <td align="left">Usage level</td> <td align="left">media</td> </tr> <tr> <td align="left">Charset dependent</td> <td align="left">No</td> </tr> <tr> <td align="left">Purpose</td> <td align="left">To define data-channel-specific parameters</td> </tr> <tr> <td align="left">Appropriate values</td> <td align="left">As per <xref target="dcmap-attr-definition"/></c> <c>O/A procedures:</c> <c>As</td> </tr> <tr> <td align="left">O/A procedures</td> <td align="left">SDP offer/answer procedures as per <xref target="section_procedures"/></c> <c>Mux category:</c> <c>SPECIAL.</td> </tr> <tr> <td align="left">Mux category</td> <td align="left">SPECIAL. See <xref target="dcmap-mux-category"/></c> <c>Reference:</c> <c>RFCXXXX</c> </texttable></td> </tr> <tr> <td align="left">Reference</td> <td align="left">RFC 8864</td> </tr> </tbody> </table> </section> <sectiontitle="dcsa"anchor="IANA-reg-dcsa"><t>NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC.</t><name>dcsa</name> <t>This document defines a new SDP media-levelattribute "a=dcsa:"attribute, "a=dcsa:", as follows: </t><texttable title=""> <ttcol align="left" width="35%"/> <ttcol align="left" width="65%"/> <c>Contact name:</c> <c>IESG</c> <c>Contact email:</c> <c>iesg@ietf.org</c> <c>Attribute name:</c> <c>dcsa</c> <c>Attribute syntax:</c> <c>As<table anchor="dcsa-iana"> <name>New "a=dcsa:" Attribute</name> <thead> <tr> <th colspan="2" align="center">"a=dcsa:"</th> </tr> </thead> <tbody> <tr> <td align="left">Contact name</td> <td align="left">IESG</td> </tr> <tr> <td align="left">Contact email</td> <td align="left">iesg@ietf.org</td> </tr> <tr> <td align="left">Attribute name</td> <td align="left">dcsa</td> </tr> <tr> <td align="left">Attribute syntax</td> <td align="left">As per <xref target="dcsa-attribute"/></c> <c>Attribute semantics:</c> <c>As</td> </tr> <tr> <td align="left">Attribute semantics</td> <td align="left">As per <xref target="dcsa-attribute"/></c> <c>Usage level:</c> <c>media</c> <c>Charset dependent:</c> <c>No</c> <c>Purpose:</c> <c>Define</td> </tr> <tr> <td align="left">Usage level</td> <td align="left">media</td> </tr> <tr> <td align="left">Charset dependent</td> <td align="left">No</td> </tr> <tr> <td align="left">Purpose</td> <td align="left">To define attributes that are specific to data channelsubprotocol specific attributes</c> <c>Appropriate values:</c> <c>Assubprotocols</td> </tr> <tr> <td align="left">Appropriate values</td> <td align="left">As per <xref target="dcsa-attribute"/></c> <c>O/A procedures:</c> <c>As</td> </tr> <tr> <td align="left">O/A procedures</td> <td align="left">SDP offer/answer procedures as per <xref target="section_procedures"/></c> <c>Mux category:</c> <c>SPECIAL.</td> </tr> <tr> <td align="left">Mux category</td> <td align="left">SPECIAL. See <xref target="dcsa-mux-category"/></c> <c>Reference:</c> <c>RFCXXXX</c> </texttable></td> </tr> <tr> <td align="left">Reference</td> <td align="left">RFC 8864</td> </tr> </tbody> </table> </section> </section></section> <section title="Contributors"> <t>Juergen Stoetzer-Bradler co-authored this document.</t> </section><sectiontitle="Acknowledgments"> <t>The authors wish to acknowledge the borrowing of ideas from other internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach and Roman Shpountanchor="IANA-reg-data-channel-attribs"> <name>Registering Attributes fortheir invaluable comments.</t> <t>Special thanks to Christer HolmbergUse with Data Channels</name> <t>When a subprotocol is defined forhelping finish the document and cleaninguse over data channels with the SDP offer/answersection.</t> </section> <section title="CHANGE LOG"> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15'"> <t> <list style="symbols"> <t>Editorial changes separate sections for offer/answer procedures.</t> <t>Update security section.</t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14'"> <t> <list style="symbols"> <t>Change "dtls-id" to "tls-id" and assign 20 octet long values</t> <t>Remove of RFC4566bis draft from list of normative references. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12'"> <t> <list style="symbols"> <t>Modification of Keith's address information. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11'"> <t> <list style="symbols"> <t>dcmap-stream-id syntax change to limit size to 5 digits. </t> <t>Add missing 'x' prefix to quoted-visible syntax. </t> <t>Align SDP offerer and answerer handling when both max-retr and max-time are present. </t> <t>Use of TEST-NET-1 ip addresses in examples. </t> <t>Add missing a=dtls-id in one example. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10'"> <t> <list style="symbols"> <t>Removal of the "a=connection" attribute lines from all SDP examples. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09'"> <t> <list style="symbols"> <t>In the introduction: <list style="symbols"> <t>Replacement of the sentence "The RTCWeb working group has defined the concept of bi-directional data channels running on top of SCTP/DTLS (SCTP over the Datagram Transport Layer Security protocol)" with "The RTCWeb working group has defined the concept of bi-directional data channels running on top of the Stream Control Transmission Protocol (SCTP)". </t> <t>Addition of following sentences to the second paragraph: "These procedures are based on generic SDP offer/answer negotiation rules for SCTP based media transport as specified in <xref target="I-D.ietf-mmusic-sctp-sdp"/> for the SDP "m" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels 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." </t> </list> </t> <t>Replacement of "DTLS connection" with "DTLS association" throughout the document. </t> <t>In sections <xref target="dcmap-mux-category"/> and <xref target="dcsa-mux-category"/> removal of the sentences "This document also does not specify multiplexing rules for this attribute for SCTP or SCTP/DTLS proto values". </t> <t>In the text related to "Subsequent SDP answer" in section <xref target="various_SDP_OA_considerations"/> replacement of "The DTLS/SCTP association remains open ..." with "The SCTP association remains open ...". </t> <t>In the text after the second SDP answer in section <xref target="examples"/> replacement of "... (after SCTP/DTLS association is setup)" with "... (after the SCTP association is set up)". </t> <t>Addition of draft-ietf-mmusic-dtls-sdp to the list of informative references. </t> <t>Addition of "a=dtls-id" attribute lines to the SDP offer/answer examples in <xref target="examples"/>. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08'"> <t> <list style="symbols"> <t>Addition of definition of "data channel subprotocol" to <xref target="terminology"/> as proposed on the MMUSIC list, https://www.ietf.org/mail-archive/web/mmusic/current/msg15827.html. </t> <t>Addition of RFC4566bis draft to list of normative references. </t> <t>Updates of tables in <xref target="IANA-reg-dcmap"/> and <xref target="IANA-reg-dcsa"/> as per section 8.2.4 of RFC4566bis draft. </t> <t>Addition of new "new-usage-level">. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07'"> <t> <list style="symbols"> <t>Addition of two new paragraphs to <xref target="dcsa-attribute"/> regarding subprotocol attribute relationship with transport protocol. </t> <t>Addition of a note to <xref target="IANA_subproto_ids"/> regarding subprotocols simultaneously defined for data channel and Websocket usage. </t> <t>Addition of two further SDP offer/answer considerations to <xref target="various_SDP_OA_considerations"/> regarding unknown subprotocol attributes and known subprotocol attributes with unknown data channel transport related semantic. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06'"> <t> <list style="symbols"> <t>Changes addressing Christian Groves's WGLC review comments raised in http://www.ietf.org/mail-archive/web/mmusic/current/msg15357.html and http://www.ietf.org/mail-archive/web/mmusic/current/msg15359.html. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05'"> <t> <list style="symbols"> <t>In IANA registration <xref target="IANA-reg-dcmap"/> and <xref target="IANA-reg-dcsa"/> replacement of contact name and e-mail address with "MMUSIC Chairs" and "mmusic-chairs@ietf.org". </t> <t>In <xref target="dcsa-attribute"/> replacement of "Thus in the example above, the original attribute line "a=accept- types:text/plain" is represented by the attribute line "a=dcsa:2 accept-types:text/plain", which specifies that this instance of MSRP being transported on the SCTP association using the data channel with stream id 2 accepts plain text files." with "... which specifies that this instance of the MSRP subprotocol being transported ...". </t> <t>The last paragraph of <xref target="dcsa-attribute"/> started with "Note: This document does not provide a complete specification ...". Removal of "Note:" and move of this paragraph to the introduction in <xref target="introduction"/> as last paragraph. </t> <t> <xref target="prot_att"/>'s headline was "Subprotocol Specific Attributes". Change of this headline to "Other Media Level Attributes" and adaptations of the first paragraph of this section and the first paragraph of <xref target="dcsa-attribute"/> in order to clarify that not only those attributes may be encapsulated in a "dcsa" attribute, which are specifically defined for the subprotocol, but that also other attributes may be encapsulated if they are related to the specific subprotocol instance. </t> <t>Move of the last but one paragraph of <xref target="dcsa-attribute"/> starting with "The same syntax applies to ..." right in front of the formal syntax definition of the "dcsa" attribute. </t> <t>Modifications of the text in <xref target="dcmap-mux-category"/> and <xref target="dcsa-mux-category"/> in order not to explicitly restrict usage of the "a=dcmap:" and "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP". </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04'"> <t> <list style="symbols"> <t>In <xref target="subprotocol-parameter"/> the first (and only) paragraph was "The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string." Replacement of this paragraph with following two paragraphs: <list style="symbols"> <t> The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. This parameter maps to the 'Protocol' parameter defined in <xref target="I-D.ietf-rtcweb-data-protocol"/>. <xref target="IANA_subproto_ids"/> specifies how new subprotocol parameter values are registered. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string. </t> <t>Note: The empty string MAY also be explicitly used as 'subprotocol' value, such that 'subprotocol=""' is equivalent to the 'subprotocol' parameter not being present at all. <xref target="I-D.ietf-rtcweb-data-protocol"/> allows the DATA_CHANNEL_OPEN message's 'subprotocol' value to be an empty string. </t> </list> </t> <t>Addition of <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> to list the of normative references. </t> <t>Addition of dcmap attribute specific IANA registration <xref target="IANA-reg-dcmap"/>. </t> <t>Addition of dcsa attribute specific IANA registration <xref target="IANA-reg-dcsa"/>. </t> <t>Addition of new <xref target="dcmap-mux-category"/> describing the mux category of the dcmap SDP attribute. This section and the new "a=dcsa:" attribute related mux category section are similar to the "Mux Category" sections of the "a=sctp-port:" and "a=max-message-size:" attributes in <xref target="I-D.ietf-mmusic-sctp-sdp"/>. </t> <t>Addition of new <xref target="dcsa-mux-category"/> describing the mux category of the dcsa SDP attribute. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03'"> <t> <list style="symbols"> <t>In <xref target="introduction"/> replacement of "RTCWeb leaves it open for other applications to use data channels and its in-band DCEP or out-of-band non-DCEP protocols for creating them" with "... to use data channels and its in-band DCEP or other in-band or out-of-band protocols for creating them". Additionally replacement of "In particular, the SDP offer generated by the application includes no channel-specific information" with "... generated by the RTCweb data channel stack includes no channel-specific information". </t> <t>Move of former section 5 ("Data Channels") to new <xref target="generic-out-of-band-aspects"/> and removal of JavaScript API specific discussions from this moved text (like mentioning of data channel stack specific states). Therefore former section 6 ("SDP Offer/Answer Negotiation") is now <xref target="sdp_synt"/>. </t> <t>In <xref target="sdp_synt"/>: <list style="symbols"> <t>Relacement of <xref target="sdp_synt"/>'s first paragraph "This section defines a method of non-DCEP negotiation by which two clients can negotiate data channel-specific and subprotocol-specific parameters, using the out-of-band SDP offer/answer exchange. This SDP extension can only be used with the SDP offer/answer model." with "This section defines an SDP extension by which two clients can negotiate data channel-specific and subprotocol-specific parameters without using DCEP <xref target="I-D.ietf-rtcweb-data-protocol"/>. This SDP extension only defines usage in the context of SDP offer/answer." </t> <t>Addition of new paragraph: "<xref target="generic-out-of-band-aspects"/> provides information how data channels work in general and especially summarizes some key aspects, which should be considered for the negotiation of data channels if DCEP is not used." </t> </list> </t> <t>In <xref target="subsec-sdp-attr-for-dc-par-neg"/> replacement of "The intention of exchanging these attributes is to create data channels on both the peers with the same set of attributes without actually using the DCEP <xref target="I-D.ietf-rtcweb-data-protocol"/>" with "The intention in exchanging these attributes is to create, on two peers, without use of DCEP <xref target="I-D.ietf-rtcweb-data-protocol"/>, matched pairs of oppositely directed data channels having the same set of attributes". </t> <t>In <xref target="max-retr-param-definition"/> replacement of "The 'max-retr' parameter indicates the maximal number a user message will be retransmitted" with "The 'max-retr' parameter indicates the maximal number of times a user message will be retransmitted". </t> <t>In <xref target="id_mngt"/> replacement of "However, an SDP offer/answer exchange MUST NOT be initiated if the associated SCTP stream is already negotiated via DCEP" with "However, an SCTP stream MUST NOT be referenced in a dcmap or dcsa attribute of an SDP offer/answer exchange if the associated SCTP stream has already been negotiated via DCEP". </t> <t>In the examples in <xref target="examples"/> addition of the previously missing colons to the "a=sctp-port" attribute lines. </t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02'"> <t> <list style="symbols"> <t>Move of reference draft-ietf-rtcweb-jsep from the list of normative references to the list of informative references. Remover in -07 since not referenced</t> <t>Addition of IANA SDP parameters to the list of informative references and addition of following two sentences to the first paragraph after the ABNF definition: "Note however that not all SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP parameters contains the lists of IANA registered session and media level or media level only SDP attributes."</t> <t>In the introduction replacement of last sentence "This document defines SDP-based out-of-band negotiation procedures to establish data channels for transport of well-defined subprotocols" with "This document defines SDP offer/answer negotiation procedures to establish data channels for transport of well-defined subprotocols, to enable out-of-band negotiation". </t> <t>Throughout the document replacement of "external negotiation" with "SDP offer/answer negotiation" and removal of term "external negotiation" from the terminology list in <xref target="terminology"/>.</t> <t> Throughout the document replacement of "internal negotiation" with "DCEP" and removal of terms "internal negotiation" and "in-band negotiation" from the terminology list in <xref target="terminology"/>.</t> <t>Addition of "SCTP Stream Sequence Number (SSN)" to the list of terms.</t> <t>In <xref target="id_mngt"/> replacement of sentence "However, a single stream is managed using one method at a time." with "However, an SDP offer/answer exchange MUST NOT be initiated if the associated SCTP stream is already negotiated via DCEP".</t> <t>In <xref target="param_negotiation"/> replacement of sentence "By definition max-retr and max-time are mutually exclusive, so only one of them can be present in a=dcmap" with "By definition max-retr and max-time are mutually exclusive, so aBoth MUST NOT be present in a=dcmap".</t> <t>Move of reference <xref target="WebRtcAPI"/> from list of normative references to list of informative references.</t> <t>Removal of almost all text parts, which discussed JavaScript or other API specific aspects. Such API specific aspects were mainly discussed in sub-sections of Section 5 and <xref target="sdp_synt"/> of draft-ietf-mmusic-data-channel-sdpneg-02.</t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01'"> <t> <list style="symbols"> <t>New <xref target="appl_statement"/> regarding applicability to SDP offer/answer only.</t> <t>Addition of new <xref target="IANA_subproto_ids"/> "Subprotocol identifiers" as subsection of the "IANA Considerations" related <xref target="IANA"/>. Also removal of the temporary note "To be completed. As [I-D.ietf-rtcweb-data-protocol] this document should refer to IANA's WebSocket Subprotocol Name Registry defined in <xref target="RFC6455"/>"</t> <t> In <xref target="param_negotiation"/>: <list style="symbols"> <t>In the first paragraph replacement of the sentence "If an SDP offer contains both of these parameters then such an SDP offer will be rejected." with "If an SDP offer contains both of these parameters then the receiver of such an SDP offer MUST reject the SDP offer." </t> <t>In the second paragraph capitalization of "shall" and "may" such that both sentences now read: "The SDP answer SHALL echo the same subprotocol, max-retr, max-time, ordered parameters, if those were present in 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."</t> <t>In the third paragraph replacement of the sentence "The same information MUST be replicated without changes in any subsequent offer or answer, as long as the data channel is still opened at the time of offer or answer generation." with "When sending a subsequent offer or an answer, and for as long as the data channel is still open, the sender MUST replicate the same information.".</t> </list> </t> <t>In <xref target="param_negotiation"/> the mapping of data channel types defined in <xref target="I-D.ietf-rtcweb-data-protocol"/> to the SDP "a=dcmap" attribute parameters were illustrated using example "a=dcmap" attribute lines. Replacement of these example "a=dcmap" attribute lines with just the "a=dcmap" attribute parameters being relevant for the channel type.</t> <t>In <xref target="various_SDP_OA_considerations"/> the description of bullet point "SDP offer has no a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: No data channel negotiated yet." Replacement of this description with "Initial SDP offer: No data channel is negotiated yet. The DTLS connection and SCTP association is negotiated and, if agreed, established as per <xref target="I-D.ietf-mmusic-sctp-sdp"/>."</t> <t>In <xref target="various_SDP_OA_considerations"/> in both bullet points related to "Subsequent SDP offer" and "Subsequent SDP answer" replacement of "All the externally negotiated data channels must be closed now." with "All the externally negotiated data channels are expected to be closed now.".</t> <t>In <xref target="ext_open"/>'s sixth paragraph replacement of the two occurrences of "must" with "MUST".</t> <t>In <xref target="dcmap-attr-definition"/> in the definition of the ABNF rule "dcmap-opt" there was a comment saying that "Only maxretr-opt or maxtime-opt is present. Both MUST NOT be present." Removal of the second normative sentence and instead addition of following new paragraph to the end of this section: "Within an 'a=dcmap' attribute line's 'dcmap-opt' value only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter is present. Both MUST NOT be present."</t> <t>In <xref target="ordered-param-description"/> replacement of the first sentence "The 'ordered' parameter with value "true" indicates that DATA chunks in the channel MUST be dispatched to the upper layer by the receiver while preserving the order." with "The 'ordered' parameter with value "true" indicates that the receiver MUST dispatch DATA chunks in the data channel to the upper layer while preserving the order.".</t> <t>In <xref target="opendc"/>'s first paragraph replacement of the one occurrence of "must" with "..., it MUST wait until ...".</t> <t>In <xref target="close-dc"/>: <list style="symbols"> <t>In the second paragraph replacement of "must" with "... whether this closing MUST in addition ..."</t> <t>In the third paragraph replacement of the sentence "The port value for the "m" line SHOULD NOT be changed (e.g., to zero) when closing a data channel ..." with "The offerer SHOULD NOT change the port value for the "m" line (e.g., to zero) when closing a data channel ...".</t> <t>In the last but two paragraph replacement of the sentence "... then an SDP offer which excludes this closed data channel SHOULD be generated." with "... then the client SHOULD generate an SDP offer which excludes this closed data channel.".</t> <t>In the last but one paragraph replacement of "must" with "The application MUST also close...".</t> </list> </t> <t>In <xref target="prot_att"/> addition of following note after the formal definition of the 'a=dcsa' attribute: "Note that the above reference to RFC 4566 defines were the attribute definition can be found; it does not provide any limitation on support of attributes defined in other documents in accordance with this attribute definition."</t> </list> </t> </section> <section title="Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00'"> <t> <list style="symbols"> <t>In <xref target="terminology"/> "WebRTC data channel" was defined as "A bidirectional channel consisting of paired SCTP outbound and inbound streams." Replacement of this definition with "Data channel: A WebRTC data channel as specified in <xref target="I-D.ietf-rtcweb-data-channel"/>", and consistent usage of "data channel" in the remainder of the document including the document's headline."</t> <t>In Section 5 removal of following note: 'OPEN ISSUE: The syntax in <xref target="I-D.ietf-mmusic-sctp-sdp"/> may change as that document progresses. In particular we expect "webrtc-datachannel" to become a more general term.'</t> <t>Consistent usage of '"m" line' in whole document as per RFC4566.</t> <t>In <xref target="subsec-sdp-attr-for-dc-par-neg"/> removal of the example dcmap attribute line 'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are already four examples right after the ABNF rules in <xref target="dcmap-attr-definition"/>. Corresponding removal of following related note: "Note: This document does not provide a complete specification of how to negotiate the use of a WebRTC data channel to transport BFCP. Procedures specific to each subprotocol such as BFCP will be documented elsewhere. The use of BFCP is only an example of how the generic procedures described herein might apply to a specific subprotocol."</t> <t>In <xref target="subsec-sdp-attr-for-dc-par-neg"/> removal of following note: "Note: This attribute is derived from attribute "webrtc-DataChannel", which was defined in old version 03 of the following draft, but which was removed along with any support for SDP external negotiation in subsequent versions: <xref target="I-D.ietf-mmusic-sctp-sdp"/>."</t> <t>Insertion of following new sentence to the beginning of <xref target="dcmap-attr-definition"/>: "dcmap is a media level attribute having following ABNF syntax:"</t> <t>Insertion of new <xref target="dcmap-stream-id-param-definition"/> containing the dcmap-stream-id specifying sentence, which previously was placed right before the formal ABNF rules. Removal of the sentence 'Stream is a mandatory parameter and is noted directly after the "a=dcmap:" attribute's colon' as this information is part of the ABNF specification.</t> <t>In <xref target="dcmap-attr-definition"/> modification of the 'ordering-value' values from "0" or "1" to "true" or "false". Corresponding text modifications in <xref target="ordered-param-description"/>.</t> <t>In <xref target="dcmap-attr-definition"/> the ABNF definition of "quoted-string" referred to rule name "escaped-char", which was not defined. Instead a rule with name "escaped" was defined. Renamed that rule's name to "escaped-char".</t> <t>Insertion of a dedicated note right after the "a=dcmap:4" attribute example in <xref target="dcmap-attr-definition"/> regarding the non-printable "escaped-char" character within the "label" value.</t> <t>In <xref target="prot_att"/>'s second paragraph replacement of "sctp stream identifier" with "SCTP stream identifier".</t> <t>In first paragraph of <xref target="id_mngt"/> replacement of first two sentences 'For the SDP-based external negotiation described in this document, the initial offerer based "SCTP over DTLS" owns by convention the even stream identifiers whereas the initial answerer owns the odd stream identifiers. This ownership is invariant for the whole lifetime of the signaling session, e.g. it does not change if the initial answerer sends a new offer to the initial offerer.' with 'If an SDP offer/answer exchange (could be the initial or a subsequent one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media description being accepted, and if this SDP offer/answer exchange results in the establishment of a new SCTP association, then the SDP 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 redetermined as well as described above.'</t> <t>In <xref target="opendc"/> the first action of an SDP answerer, when receiving an SDP offer, was described as "Applies the SDP offer. Note that the browser ignores data channel specific attributes in the SDP." Replacement of these two sentences with "Parses and applies the SDP offer. Note that the typical parser normally ignores unknown SDP attributes, which includes data channel related attributes."</t> <t>In <xref target="opendc"/> the second sentence of the third SDP answerer action was "Note that the browser is asked to create data channels with stream identifiers not "owned" by the agent.". Replacement of this sentence with "Note that the agent is asked to create data channels with SCTP stream identifiers contained in the SDP offer if the SDP offer is accepted."</t> <t>In <xref target="close-dc"/> the third paragraph began with "A data channel 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 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 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 it MUST also exclude the corresponding attribute lines in the answer. ..." Replacement of this part with "The intention to close a data channel can be signaled by sending a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute lines for the data channel. The port 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 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 it 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 it MUST also exclude the corresponding attribute lines in the answer."</t> <t>In <xref target="close-dc"/> the hanging text after the third paragraph was "This delayed close is to handle cases where a successful SDP answer is not received, in which case the state of session should be kept per the last successful SDP offer/answer." Replacement of this sentence with "This delayed closure is RECOMMENDED in order 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 successful SDP offer/answer."</t> <t>Although dedicated to "a=dcmap" and "a=dcsa"mechanism, any SDPsyntax aspects <xref target="subsec-sdp-attr-for-dc-par-neg"/> contained already procedural descriptions related to data channel reliability negotiation. Creation of new <xref target="param_negotiation"/> and moval of reliability negotiation related text to this new section.</t> </list> </t> </section> <section title="Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02'"> <t> <list style="symbols"> <t>Removal of note "ACTION ITEM" from section "subprotocol parameter". As <xref target="I-D.ietf-rtcweb-data-protocol"/> this document should refer to IANA's WebSocket Subprotocol Name Registry defined in <xref target="RFC6455"/> </t> <t>In whole document, replacement of "unreliable" with "partially reliable", which is used in <xref target="I-D.ietf-rtcweb-data-channel"/> and in <xref target="I-D.ietf-rtcweb-data-protocol"/> in most places.</t> <t>Clarification of the semantic if the "max-retr" parameter is not present in an "a=dcmap" attribute line. In section "max-retr parameter" the sentence "The max-retr parameter is optional with default value unbounded" was replaced with "The max-retr parameter is optional. If the max-retr parameter is not present, then the maximal number of retransmissions is determined as per the generic SCTP retransmission rules as specified in <xref target="RFC4960"/>".</t> <t>Clarification of the semantic if the "max-time" parameter is not present in an "a=dcmap" attribute line. In section "max-time parameter" the sentence "The max-time parameter is optional with default value unbounded" was replaced with "The max-time parameter is optional. If the max-time parameter is not present, then the generic SCTP retransmission timing rules apply as specified in <xref target="RFC4960"/>".</t> <t>In section "label parameter" the sentence "Label is a mandatory parameter." was removed and following new sentences (including the note) were added: "The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. Note: The empty stringattributes that mayalsobeexplicitly used as 'label' value, such that 'label=""' is equivalent to the 'label' parameter not being present at all. <xref target="I-D.ietf-rtcweb-data-protocol"/> allowsnegotiated using theDATA_CHANNEL_OPEN message's 'Label' value to"a=dcsa:" attribute MUST bean empty string."</t> <t>In section "subprotocol parameter" the sentence "subprotocol is a mandatory parameter." was replaced with "'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaultsadded to theempty string."</t> <t>In the "Examples" section, in the first two SDP offer examples in the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 'label="bfcp"'.</t> <t>In all examples, the "m" line proto value "DTLS/SCTP" was replaced with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were replaced with "a=max-message-size" attribute lines, as per draft-ietf-mmusic-sctp-sdp-12.</t> </list> </t> </section> <section title="Changes against '-01'"> <t> <list style="symbols"> <t>Formal syntax for dcmap and dcsa attribute lines. </t> <t>Making subprotocolIANA "attribute-name" registry (formerly "att-field"), asan optional parameterspecified indcmap. </t> <t>Specifying disallowed parameter combinations for max-time and max-retr. </t> <t>Clarifications on WebRTC data channel close procedures. </t> </list> </t> </section> <section title="Changes against '-00'"> <t> <list style="symbols"> <t> Revisions to identify difference between internal and external negotiation and their usage.</t> <t>Introduction of more generic terminology, e.g. "application" instead of "browser".</t> <t>Clarification of how "max-retr and max-time affect the usage of unreliable and reliable WebRTC data channels.</t> <t>Updates of examples to take into account the SDP syntax changes introduced with draft-ietf-mmusic-sctp-sdp-07.</t> <t>Removal<xref target="RFC8866" sectionFormat="comma" section="8.2.4"/>. This document specifies that new Usage Levels of theSCTP port number from the "a=dcmap" and "a=dcsa" attributes as thisform "dcsa (foo)" (where "foo" isnow contained ina placeholder for thea=sctp-port attribute, and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP association on topsubprotocol name) should be registered by documents that specify negotiation ofthe DTLS connection.</t> </list> </t>particular subprotocols.</t> </section> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC4960; &RFC8174; &RFC3264; &RFC5234; &RFC6525; &RFC3629; &DATAREQ; &SDPBIS; &SDPSCTP; &SDPMUXATTR; &DATAPROTO; </references> <references title="Informative References"> &RFC4582; &RFC4975; &RFC6455; &CLUEDATA; &MSRPDATA;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6525.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> <!-- draft-ietf-rtcweb-data-channel (RFC 8831) --> <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831"> <front> <title>WebRTC Data Channels</title> <author initials="R" surname="Jesup" fullname="Randell Jesup"> <organization/> </author> <author initials="S" surname="Loreto" fullname="Salvatore Loreto"> <organization/> </author> <author initials="M" surname="Tüxen" fullname="Michael Tüxen"> <organization/> </author> <date month='September' year='2020'/> </front> <seriesInfo name="RFC" value="8831"/> <seriesInfo name="DOI" value="10.17487/RFC8831"/> </reference> <!-- draft-ietf-mmusic-rfc4566bis (RFC 8866) --> <reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8866"> <front> <title>SDP: Session Description Protocol</title> <author initials="A" surname="Begen" fullname="Ali Begen"> <organization/> </author> <author initials="P" surname="Kyzivat" fullname="Paul Kyzivat"> <organization/> </author> <author initials="C" surname="Perkins" fullname="Colin Perkins"> <organization/> </author> <author initials="M" surname="Handley" fullname="Mark Handley"> <organization/> </author> <date month="September" year="2020"/> </front> <seriesInfo name="RFC" value="8866"/> <seriesInfo name="DOI" value="10.17487/RFC8866"/> </reference> <!-- draft-ietf-mmusic-sctp-sdp (RFC 8841) --> <reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8841"> <front> <title>Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport</title> <author initials="C." surname="Holmberg" fullname="Christer Holmberg"> <organization /> </author> <author initials="R." surname="Shpount" fullname="Roman Shpount"> <organization /> </author> <author initials="S." surname="Loreto" fullname="Salvatore Loreto"> <organization /> </author> <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo"> <organization /> </author> <date month="September" year="2020" /> </front> <seriesInfo name="RFC" value="8841" /> <seriesInfo name="DOI" value="10.17487/RFC8841"/> </reference> <!-- draft-ietf-mmusic-sdp-mux-attributes (RFC 8859) --> <referenceanchor="WebRtcAPI" target="https://www.w3.org/TR/2018/CR-webrtc-20180927/">anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859"> <front><title> WebRTC 1.0: Real-time Communication Between Browsers </title><title>A Framework for Session Description Protocol (SDP) Attributes When Multiplexing</title> <authorinitials="A." surname="Bergkvist" fullname="Adam Bergkvist">initials="S" surname="Nandakumar" fullname="Suhas Nandakumar"> <organization/> </author> <date month="September" year="2020"/> </front> <seriesInfo name="RFC" value="8859"/> <seriesInfo name="DOI" value="10.17487/RFC8859"/> </reference> <!--draft-ietf-rtcweb-data-protocol (RFC 8832) --> <reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832"> <front> <title>WebRTC Data Channel Establishment Protocol</title> <authorinitials="D." surname="Burnett" fullname="Daniel Burnett">initials='R.' surname='Jesup' fullname='Randell Jesup'> <organization/> </author> <authorinitials="C." surname="Jennings" fullname="Cullen Jennings">initials='S.' surname='Loreto' fullname='Salvatore Loreto'> <organization/> </author> <authorinitials="A." surname="Narayanan" fullname="Anant Narayanan">initials='M' surname='Tüxen' fullname='Michael Tüxen'> <organization/> </author> <date month='September' year='2020'/> </front> <seriesInfo name="RFC" value="8832"/> <seriesInfo name="DOI" value="10.17487/RFC8832"/> </reference> </references> <references> <name>Informative References</name> <!-- Watch to see if 4582bis gets published before this doc. --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4582.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4975.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml"/> <!--draft-ietf-clue-datachannel (RFC 8850) --> <reference anchor='RFC8850' target='https://www.rfc-editor.org/info/rfc8850'> <front> <title>Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel</title> <author initials='C' surname='Holmberg' fullname='Christer Holmberg'> <organization /> </author> <date month='September' year='2020' /> </front> <seriesInfo name='RFC' value='8850' /> <seriesInfo name='DOI' value='10.17487/RFC8850' /> </reference> <!-- draft-ietf-mmusic-msrp-usage-data-channel (Submitted to IESG for Pub) Needs "long way" because Jose Recio is an editor --> <reference anchor='MSRP-over-Data-Channels'> <front> <title>MSRP over Data Channels</title> <author initials='J' surname='Recio' fullname='Jose Recio' role='editor'> <organization /> </author> <author initials='C' surname='Holmberg' fullname='Christer Holmberg'> <organization /> </author> <date month='August' day='18' year='2020' /> </front> <seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-msrp-usage-data-channel-24' /> </reference> <reference anchor="WebRtcAPI" target="https://www.w3.org/TR/2019/CR-webrtc-20191213/"> <front> <title>WebRTC 1.0: Real-time Communication Between Browsers</title> <authorinitials="B." surname="Aboba" fullname="Bernard Aboba">initials="C." surname="Jennings" fullname="Cullen Jennings"> <organization/> </author> <authorinitials="T." surname="Brandstetter" fullname="Taylor Brandstetter">initials="H." surname="Boström" fullname="Henrik Boström"> <organization/> </author> <authorinitials="J."initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey"> <organization/> </author> <datemonth="September" day="27" year="2018"/>year="2019" month="December" day="13"/> </front> <refcontent>W3C Candidate Recommendation</refcontent> </reference> <reference anchor="T38" target="https://www.itu.int/rec/T-REC-T.38-201511-I/en"> <front> <title>Procedures for real-time Group 3 facsimile communication over IP networks</title> <author> <organization>International Telecommunication Union</organization> </author> <date month="November" year="2015"/> </front> <seriesInfoname="World Wide Web Consortium CR" value="CR-webrtc-20180927"/> <format type="HTML" target="https://www.w3.org/TR/2018/CR-webrtc-20180927"/>name="ITU-T Recommendation" value="T.38"/> </reference> </references> </references> <sectiontitle="Genericanchor="generic-out-of-band-aspects"> <name>Generic Data Channel Negotiation AspectsWhenwhen Not UsingDCEP" anchor="generic-out-of-band-aspects">DCEP</name> <t>This appendix summarizes how data channels work in general and discusses some keyaspects, whichaspects that should be considered for the out-of-band negotiation of data channels if DCEP is not used.</t> <t>A WebRTC application creates a data channel by providing a number of setup parameters (subprotocol, label, maximal number of retransmissions, maximal retransmission time, order of delivery, priority). The application also specifiesifwhether it wants to make use of the negotiation usingtheDCEP <xreftarget="I-D.ietf-rtcweb-data-protocol"/>,target="RFC8832"/> orif the applicationintends to negotiate data channels using the SDP offer/answer protocol.</t> <t>In any case, the SDP offer generated by the application is per <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>.target="RFC8841"/>. In brief, it contains one"m""m=" line for the SCTP association on top of which the data channels willrun:</t> <figure align="left" title=""> <artwork align="left"><![CDATA[run: </t> <sourcecode name="app-a-sdp-example" type="sdp"><![CDATA[ m=application 54111 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=tls-id:abc3de65cddef001be82 a=setup:actpass a=fingerprint:SHA-1 \4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB ]]></artwork> </figure> <t>Note:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB]]></sourcecode> <aside><t>Note: A WebRTC application will only use"m"the "m=" line format"webrtc-datachannel","webrtc-datachannel" and will not use other formats in the"m""m=" line for other protocols such ast38.T.38 <xref target="T38"/>. <xreftarget="I-D.ietf-mmusic-sctp-sdp"/>target="RFC8841"/> supports only one SCTP association to be established on top of a DTLS association.</t> <t>Note:</t></aside> <aside><t>Note: The above SDP media description does not contain any channel-specificinformation.</t>information.</t></aside> <sectiontitle="Stream Identifier Numbering"anchor="si_num"> <name>Stream Identifier Numbering</name> <t>Independently from the requested type of negotiation, the application creating a data channel can eitherpass(1) pass the stream identifier to the data channel stack to assign to the data channel orelse let(2) let the data channel stack pick one identifier from the unused ones.</t><t>To<t>Moreover, to avoid glare situations <xref target="RFC3264"/>, each endpoint canmoreoverown an exclusive set of stream identifiers, in which case an endpoint can only create a data channel with a stream identifier it owns.</t> <t>Which set of stream identifiers is owned by which endpoint is determined by convention or other means.<list style="hanging"> <t>Note:For</t> <aside><t>Note: For data channels negotiated withtheDCEP, one endpoint owns by convention the even stream identifiers, whereas the other owns the odd stream identifiers, as defined in <xreftarget="I-D.ietf-rtcweb-data-protocol"/>.</t> <t>Note:Fortarget="RFC8832"/>.</t></aside> <aside><t>Note: For data channels negotiated viadifferenta protocolfromother than DCEP, no convention is defined bydefault.</t> </list> </t>default.</t></aside> </section> <sectiontitle="Genericanchor="sec-gen-ext-neg"> <name>Generic Data Channel Negotiation Not UsingDCEP" anchor="sec-gen-ext-neg"> <section title="Overview">DCEP</name> <section> <name>Overview</name> <t>DCEP negotiation only provides for negotiation of data channel transport parameters and does not provide for negotiation ofsubprotocol specificsubprotocol-specific parameters.DCEP-lessNon-DCEP data channel negotiation can be defined to allow negotiation of parameters beyond those handled by DCEP, e.g., parameters specific to the subprotocol instantiated on a particular data channel.</t> <t>The following procedures are common to all methods of data channel negotiation not using DCEP, whether in-band (communicated using proprietary means on analready establishedalready-established data channel) or out-of-band (using the SDP offer/answer mechanism or some other protocol associated with the signaling channel).</t> </section> <sectiontitle="Openinganchor="ext_open"> <name>Opening a DataChannel" anchor="ext_open">Channel</name> <t>In the case ofDCEP-lessnon-DCEP negotiation, the endpoint application has the option to fully control the stream identifier assignments.HoweverHowever, these assignments have to coexist with the assignments controlled by the data channel stack forthe DCEP negotiateddata channels negotiated using DCEP (if any). It is the responsibility of the application to ensure consistent assignment of stream identifiers.</t> <t>When the application requests that the creation of a new data channeltobe set up viaDCEP-lessnon-DCEP negotiation, the data channel stack creates the data channel locally without sending any DATA_CHANNEL_OPENmessagemessages in-band. However, even if the ICE (Interactive Connectivity Establishment),DTLSDTLS, and SCTP procedures were already successfully completed, the application can't send data on this data channel until the negotiationis completewith thepeer.peer is complete. This is because the peer needs to be aware of and accept the usage of this data channel. The peer, after accepting the data channel offer, can start sending data immediately. This implies that the offerer may receive data channel subprotocol messages before the negotiation iscompletecomplete, and the application should be ready to handle it.</t> <t>If the peer rejects the data channel part of theofferoffer, then it doesn't have to doanythinganything, as the data channel was not created using the stack. Theoffererofferer, on the otherhandhand, needs to close the data channel that was opened by invoking relevant data channel stack API procedures.</t> <t>It is also worth noting that a data channel stack implementation may not provide anyAPIAPIs to create and close data channels;insteadinstead, the data channels may be used on the fly asneededneeded, just by communicating via non-DCEP means orbyeven by having some local configuration/assumptions on both of the peers.</t> <t>The application then negotiates the data channel properties and subprotocol properties with the peer's application using a mechanism different from DCEP.</t> <t>The peer then symmetrically creates a data channel with these negotiated data channel properties. This is the only way for the peer's data channel stack to know which properties to apply when transmitting data on this channel. The data channel stack must allow data channel creation with anynon-conflictingnonconflicting stream identifier so that both peers can create the data channel with the same stream identifier. </t> </section><section title="Closing<section> <name>Closing a DataChannel">Channel</name> <t>When the application requests the closing of a data channel negotiated without DCEP, the data channel stack always performs an SCTP SSNresetReset for this channel.</t> <t>Depending upon the method used forDCEP-lessnon-DCEP negotiation and the subprotocol associated with the data channel, the closing of the data channel mightin additionalso be signaled to the peer via SDP offer/answer negotiation.</t> </section> </section><!-- sec-gen-ext-neg --></section><!-- generic-out-of-band-aspects --><section anchor="acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>The authors wish to acknowledge the borrowing of ideas from other draft documents by <contact fullname="Salvatore Loreto"/>, <contact fullname="Gonzalo Camarillo"/>, <contact fullname="Peter Dunkley"/>, and <contact fullname="Gavin Llewellyn"/>. The authors also wish to thank <contact fullname="Flemming Andreasen"/>, <contact fullname="Christian Groves"/>, <contact fullname="Gunnar Hellström"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Jonathan Lennox"/>, <contact fullname="Uwe Rauschenbach"/>, and <contact fullname="Roman Shpount"/> for their invaluable comments.</t> <t>Special thanks to <contact fullname="Christer Holmberg"/> for helping finish the document and cleaning up <xref target="section_procedures"/>. </t> </section> <section anchor="contributors" numbered="false"> <name>Contributors</name> <t><contact fullname="Juergen Stoetzer-Bradler"/> made significant contributions to this document and should be considered a coauthor.</t> </section> </back> </rfc>