rfc8841xml2.original.xml   rfc8841.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='utf-8'?>
<?rfc symrefs="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<rfc category="std" docName="draft-ietf-mmusic-sctp-sdp-26" ipr="trust200902">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
docName="draft-ietf-mmusic-sctp-sdp-26" ipr="trust200902" obsoletes=""
updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" version="3" number="8841" consensus="true">
<front> <!-- xml2rfc v2v3 conversion 2.34.0 -->
<title abbrev="SDP Offer/Answer For SCTP Over DTLS">
Session Description Protocol (SDP) Offer/Answer Procedures
For Stream Control Transmission Protocol (SCTP) over
Datagram Transport Layer Security (DTLS) Transport.
</title>
<front>
<title abbrev="SDP Offer/Answer for SCTP over DTLS">
Session Description Protocol (SDP) Offer/Answer Procedures
for Stream Control Transmission Protocol (SCTP) over
Datagram Transport Layer Security (DTLS) Transport
</title>
<seriesInfo name="RFC" value="8841" />
<author initials="C." surname="Holmberg" fullname="Christer Holmberg"> <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<code>02420</code> <code>02420</code>
<city>Jorvas</city> <city>Jorvas</city>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>christer.holmberg@ericsson.com</email> <email>christer.holmberg@ericsson.com</email>
</address> </address>
</author> </author>
<author fullname="Roman Shpount" initials="R.S." surname="Shpount"> <author fullname="Roman Shpount" initials="R." surname="Shpount">
<organization abbrev="TurboBridge">TurboBridge</organization> <organization abbrev="TurboBridge">TurboBridge</organization>
<address> <address>
<postal> <postal>
<street>4905 Del Ray Avenue, Suite 300</street> <street>4905 Del Ray Avenue, Suite 300</street>
<city>Bethesda</city> <city>Bethesda</city>
<region>MD</region> <region>MD</region>
<code>20814</code> <code>20814</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 (240) 292-6632</phone> <phone>+1 (240) 292-6632</phone>
<email>rshpount@turbobridge.com</email> <email>rshpount@turbobridge.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto"> <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Grönlandsgatan 31</street>
<code>02420</code> <city>Kista</city>
<city>Jorvas</city> <country>Sweden</country>
<country>Finland</country> </postal>
</postal> <email>Salvatore.Loreto@ericsson.com</email>
<email>Salvatore.Loreto@ericsson.com</email> </address>
</address>
</author> </author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo"> <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<code>02420</code> <code>02420</code>
<city>Jorvas</city> <city>Jorvas</city>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>Gonzalo.Camarillo@ericsson.com</email> <email>Gonzalo.Camarillo@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2021" month="January"/>
<date year="2017"/> <area>ART</area>
<area>RAI</area>
<workgroup>MMUSIC</workgroup> <workgroup>MMUSIC</workgroup>
<keyword>SCTP, SDP, DTLS</keyword> <keyword>SCTP</keyword>
<keyword>SDP</keyword>
<keyword>DTLS</keyword>
<abstract> <abstract>
<t> <t>
The Stream Control Transmission Protocol (SCTP) is a transport proto col The Stream Control Transmission Protocol (SCTP) is a transport proto col
used to establish associations between two endpoints. used to establish associations between two endpoints.
draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used RFC 8261 specifies how SCTP can be used on
on top of the Datagram Transport Layer Security (DTLS) protocol,
top of the Datagram Transport Layer Security (DTLS) protocol, referr which is referred to as SCTP-over-DTLS.
ed to </t>
as SCTP-over-DTLS. <t>
</t>
<t>
This specification defines the following new Session Description Pro tocol (SDP) This specification defines the following new Session Description Pro tocol (SDP)
protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SC TP'. This protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/S CTP". This
specification also specifies how to use the new proto values with th e specification also specifies how to use the new proto values with th e
SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associatio SDP offer/answer mechanism for negotiating SCTP-over-DTLS associatio
ns. ns.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
SDP (Session Description Protocol) <xref target="RFC4566"/> provides The Session Description Protocol (SDP) <xref target="RFC4566"
a format="default"/> provides a
general-purpose format for describing multimedia sessions in announc general-purpose format for describing multimedia sessions in announcemen
ements ts
or invitations. TCP-Based Media Transport in the Session Description or invitations. "TCP-Based Media Transport in the Session Description Pr
Protocol otocol
(SDP) <xref target="RFC4145"/> specifies a general mechanism for des (SDP)" <xref target="RFC4145" format="default"/> specifies a general
cribing and mechanism for describing and
establishing TCP <xref target="RFC0793"/> streams. establishing TCP <xref target="RFC0793" format="default"/> streams.
Connection-Oriented Media Transport over the Transport Layer Securit "Connection-Oriented Media Transport over the Transport Layer Security (
y (TLS) TLS)
Protocol in SDP <xref target="RFC8122"/> extends RFC4145 <xref targe Protocol in the Session Description Protocol (SDP)" <xref
t="RFC4145"/> for target="RFC8122" format="default"/> extends
describing TCP-based media streams that are protected using TLS. <xref target="RFC4145" format="default"/> to describe TCP-based media
</t> streams that are protected using TLS.
<t> </t>
The Stream Control Transmission Protocol (SCTP) <xref target="RFC496 <t>
0"/> is a The Stream Control Transmission Protocol (SCTP) <xref target="RFC496
0" format="default"/> is a
reliable transport protocol used to transport data between two reliable transport protocol used to transport data between two
endpoints using SCTP associations. endpoints using SCTP associations.
</t> </t>
<t> <t>
<xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/> specifies how SCTP can be <xref target="RFC8261" format="default"/> specifies how SCTP can be used o
used on n
top of the Datagram Transport Layer Security (DTLS) protocol, referred to top of the Datagram Transport Layer Security (DTLS) protocol, an
arrangement referred to
as SCTP-over-DTLS. as SCTP-over-DTLS.
</t> </t>
<t> <t>
This specification defines the following new Session Description Protocol This specification defines the following new SDP
(SDP) <xref target="RFC4566" format="default"/> protocol identifiers (proto
<xref target="RFC4566"/> protocol identifiers (proto values):'UDP/DTLS/SCT values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This document also
P' specifies how to use the new proto
and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new values with the SDP offer/answer mechanism <xref target="RFC3264"
proto format="default"/> for negotiating
values with the SDP Offer/Answer mechanism <xref target="RFC3264"/> for ne
gotiating
SCTP-over-DTLS associations. SCTP-over-DTLS associations.
</t> </t>
<t> <aside>
<t>
NOTE: Due to the characteristics of TCP, while multiple SCTP streams can s till NOTE: Due to the characteristics of TCP, while multiple SCTP streams can s till
be used, usage of 'TCP/DTLS/SCTP' will always force ordered and reliable d elivery be used, usage of "TCP/DTLS/SCTP" will always force ordered and reliable d elivery
of the SCTP packets, which limits the usage of the SCTP options. Therefore , it is of the SCTP packets, which limits the usage of the SCTP options. Therefore , it is
RECOMMENDED that TCP is only used in situations where UDP traffic is block <bcp14>RECOMMENDED</bcp14> that TCP is only used in situations where UDP t
ed. raffic is blocked.
</t> </t>
</section> </aside>
</section>
<section title="Conventions"> <section numbered="true" toc="default">
<t> <name>Conventions</name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
document are to be interpreted as described in <xref target="RFC2119"></xref "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
>. NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</section> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="SCTP Terminology"> </section>
<t> <section numbered="true" toc="default">
SCTP Association: A protocol relationship between SCTP endpoints, <name>SCTP Terminology</name>
<dl>
<dt>SCTP association:</dt>
<dd>A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information composed of the two SCTP endpoints and protocol state information
including Verification Tags and the currently active set of including verification tags and the currently active set of
Transmission Sequence Numbers (TSNs), etc. An association can be Transmission Sequence Numbers (TSNs), etc. An association can be
uniquely identified by the transport addresses used by the uniquely identified by the transport addresses used by the
endpoints in the association. endpoints in the association.</dd>
</t>
<t> <dt>SCTP stream:</dt>
SCTP Stream: A unidirectional logical channel established from one to <dd>A unidirectional logical channel established from one associated
another associated SCTP endpoint, within which all user messages SCTP endpoint to
another, within which all user messages
are delivered in sequence except for those submitted to the are delivered in sequence except for those submitted to the
unordered delivery service. unordered delivery service.</dd>
</t>
<t>
SCTP-over-DTLS: SCTP used on top of DTLS, as specified in
<xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>.
</t>
</section>
<section title="SDP Media Descriptions" anchor="m-line"> <dt>SCTP-over-DTLS:</dt>
<section title="General" anchor="m-line-gen"> <dd>SCTP used on top of DTLS, as specified in
<t> <xref target="RFC8261" format="default"/>.</dd>
This section defines the following new SDP Media Description (m- </dl>
</section>
<section anchor="m-line" numbered="true" toc="default">
<name>SDP Media Descriptions</name>
<section anchor="m-line-gen" numbered="true" toc="default">
<name>General</name>
<t>
This section defines the following new SDP media description ("m="
line) protocol identifiers (proto values) for describing an SCTP line) protocol identifiers (proto values) for describing an SCTP
association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The section als association: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". The section als
o o
describes how an m- line, associated with the proto values, is describes how an "m=" line associated with the proto values is
created. created.
</t> </t>
<t> <t>
The following is the format for an m- line, as specified in RFC456 The following is the format for an "m=" line, as specified in
6 <xref target="RFC4566" format="default"/>:
<xref target="RFC4566"/>: </t>
</t> <sourcecode><![CDATA[
<figure> m=<media> <port> <proto> <fmt> ...
<artwork><![CDATA[ ]]></sourcecode>
m=<media> <port> <proto> <fmt> ... <t>
]]></artwork> The "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values are similar t
</figure> o both
<t> the "UDP" and "TCP" proto values in that they only describe the tr
The 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are similar t ansport-layer
o both
the 'UDP' and 'TCP' proto values in that they only describe the tr
ansport-layer
protocol and not the upper-layer protocol. protocol and not the upper-layer protocol.
</t> </t>
<t> <aside>
NOTE: When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values ar <t>
e used, NOTE: When the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values ar
the underlying transport protocol is respectively UDP and TCP; SCT e used,
P is the underlying transport protocol is, respectively, UDP and TCP; S
carried on top of DTLS which is on top of those transport-layer pr CTP is
otocols. carried on top of DTLS, which is on top of those transport-layer p
</t> rotocols.
</t>
</aside>
</section> </section>
<section anchor="proto" numbered="true" toc="default">
<section title="Protocol Identifiers" anchor="proto"> <name>Protocol Identifiers</name>
<t> <t>
The new proto values are defined as below: The new proto values are defined as below:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t> The "UDP/DTLS/SCTP" proto value describes an SCTP association on top o
The 'UDP/DTLS/SCTP' proto value describes an SCTP associat f
ion on top of a DTLS association on top of UDP, as defined in
a DTLS association on top of UDP, as defined in <xref target="sec-udp-dtls-sctp" format="default"/>.
<xref target="sec-udp-dtls-sctp"/>. </li>
</t> <li>
<t> The "TCP/DTLS/SCTP" proto value describes an SCTP association on top
The 'TCP/DTLS/SCTP' proto value describes an SCTP associat of
ion on top of a DTLS association on top of TCP, as defined in <xref
a DTLS association on top of TCP, as defined in <xref targ target="sec-tcp-dtls-sctp" format="default"/>.
et="sec-tcp-dtls-sctp"/>. </li>
</t> </ul>
</list>
</t>
</section> </section>
<section anchor="media" numbered="true" toc="default">
<section title="Media Format Management" anchor="media"> <name>Media-Format Management</name>
<t> <t>
<xref target="RFC4566"/> defines that specifications defining new <xref target="RFC4566" format="default"/> states that
proto values must specifications defining new proto values must
define the rules by which their media format (fmt) namespace is ma naged. define the rules by which their media format (fmt) namespace is ma naged.
</t> </t>
<t> <t>
An m- line with a proto value of 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP An "m=" line with a proto value of "UDP/DTLS/SCTP" or "TCP/DTLS/SC
' TP"
always describes a single SCTP association. always describes a single SCTP association.
</t> </t>
<t> <t>
In addition, such m- line MUST further indicate the application-la In addition, such an "m=" line <bcp14>MUST</bcp14> further indicat
yer protocol e
using an 'fmt' identifier. There MUST be exactly one fmt value per the application-layer protocol
m- line associated using an "fmt" identifier. There <bcp14>MUST</bcp14> be exactly
with the proto values defined in this specification. The 'fmt' nam one fmt value per "m=" line associated
espace associated with the proto values defined in this specification. The "fmt"
with those proto values describes the generic application usage of namespace associated
the entire SCTP with those proto values describes the generic application usage
of the entire SCTP
association, including the associated SCTP streams. association, including the associated SCTP streams.
</t> </t>
<t>
When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- <t>
line fmt value, When the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" proto values are
identifying the application-layer protocol, MUST be registered by used, the "m=" line fmt value, which identifies the
IANA. application-layer protocol, <bcp14>MUST</bcp14> be registered by
<xref format="default" pageno="false" target="iana-assusage-regist IANA. <xref format="default" target="iana-assusage-registry"/>
ry"/> defines the defines the IANA registry for the media-format namespace.
IANA registry for the media format namespace. </t>
</t> <aside>
<t> <t>
NOTE: A mechanism on how to describe, and manage, individual SCTP NOTE: A mechanism for how to describe and manage individual
streams within an SCTP streams within an
SCTP association, is outside the scope of this specification. <xre SCTP association is outside the scope of this
f format="default" specification. <xref format="default"
pageno="false" target="I-D.ietf-mmusic-data-channel-sdpneg"/> defi target="RFC8864"/> defines
nes
a mechanism for negotiating individual SCTP streams used to realiz e WebRTC a mechanism for negotiating individual SCTP streams used to realiz e WebRTC
data channels <xref format="default" pageno="false" target="I-D.ie data channels <xref format="default" target="RFC8831"/>.
tf-rtcweb-data-channel"/>. </t>
</t> </aside>
</section> </section>
<section anchor="m-line-syn" numbered="true" toc="default">
<section title="Syntax" anchor="m-line-syn"> <name>Syntax</name>
<section title="General"> <section numbered="true" toc="default">
<t> <name>General</name>
<t>
This section defines the values that can be used within an This section defines the values that can be used within an
SDP media description ("m=" line) associated with an SDP media description ("m=" line) associated with an
SCTP-over-DTLS association. SCTP-over-DTLS association.
</t> </t>
<t> <t>
This specification creates an IANA registry for 'association-u This specification creates an IANA registry for "association-u
sage' values. sage" values.
</t> </t>
</section> </section>
<section title="SDP Media Description values"> <section numbered="true" toc="default">
<figure> <name>SDP Media Description Values</name>
<artwork><![CDATA[ <t>
When the SCTP association is used to realize a WebRTC data channel
<xref target="RFC8832"/>, the &lt;fmt&gt; parameter value is 'webrtc-datachannel
'.
</t>
m= line parameter parameter value(s) <table anchor="media-desc">
------------------------------------------------------------------ <name>SDP Media Description Values</name>
<media>: 'application' <thead>
<proto>: 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP' <tr>
<port>: UDP port number (for 'UDP/DTLS/SCTP') <th>"m=" line parameter</th>
TCP port number (for 'TCP/DTLS/SCTP') <th>parameter value(s)</th>
<fmt>: a string denoting the association-usage, </tr>
limited to the syntax of a 'token' as </thead>
defined in RFC4566. <tbody>
<tr>
<td>&lt;media&gt;</td>
<td>"application"</td>
</tr>
]]></artwork> <tr>
</figure> <td>&lt;proto&gt;</td>
</section> <td>"UDP/DTLS/SCTP" or "TCP/DTLS/SCTP"</td>
</tr>
<tr>
<td>&lt;port&gt;</td>
<td>UDP port number (for "UDP/DTLS/SCTP")<br/>TCP port number (for "TCP/DT
LS/SCTP")</td>
</tr>
<tr>
<td>&lt;fmt&gt;</td>
<td>A string denoting the association-usage, limited to the syntax of a
"token" as defined in RFC 4566</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
<section title="Example">
<figure>
<artwork><![CDATA[
<section numbered="true" toc="default">
<name>Example</name>
<sourcecode type="sdp">
m=application 12345 UDP/DTLS/SCTP webrtc-datachannel m=application 12345 UDP/DTLS/SCTP webrtc-datachannel
a=sctp-port:5000 a=sctp-port:5000
a=max-message-size:100000 a=max-message-size:100000</sourcecode>
]]></artwork> <aside>
</figure> <t>
<t> NOTE: "webrtc-datachannel" indicates the WebRTC Data Channel
NOTE: 'webrtc-datachannel' indicates the WebRTC Data Channel Estab Establishment Protocol defined in <xref target="RFC8832"
lishment Protocol format="default"/>.
defined in <xref target="I-D.ietf-rtcweb-data-protocol"/>. </t>
</t> </aside>
</section> </section>
</section> </section>
<section anchor="attr-sctp-port" numbered="true" toc="default">
<section title="SDP 'sctp-port' Attribute" anchor="attr-sctp-port"> <name>SDP "sctp-port" Attribute</name>
<section title="General" anchor="attr-sctp-port-gen"> <section anchor="attr-sctp-port-gen" numbered="true" toc="default">
<t> <name>General</name>
This section defines a new SDP media-level attribute, 'sctp-port'. <t>
The attribute can be associated with an SDP media description (m- This section defines a new SDP media-level attribute,
line) "sctp-port". The attribute can be associated with an SDP media
with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value. In that c description ("m=" line) with a "UDP/DTLS/SCTP" or a
ase "TCP/DTLS/SCTP" proto value. In that case, the "m=" line port
the m- line port value indicates the port of the underlying transp value indicates the port of the underlying transport-layer
ort layer protocol (UDP or TCP), and the "sctp-port" value indicates the
protocol (UDP or TCP), and the 'sctp-port' value indicates the SCT SCTP port.
P port. </t>
</t> <t>
<t> No default value is defined for the SDP "sctp-port"
No default value is defined for the SDP sctp-port attribute. There attribute. Therefore, if the attribute is not present, the
fore, if associated "m=" line <bcp14>MUST</bcp14> be considered invalid.
the attribute is not present, the associated m- line MUST be consi </t>
dered invalid. <aside>
</t> <t>
<t> NOTE: This specification only defines the usage of the SDP
NOTE: This specification only defines the usage of the SDP 'sctp-p "sctp-port" attribute when associated with an "m=" line containing
ort' one of the following proto values: "UDP/DTLS/SCTP" or
attribute when associated with an m- line containing one of the fo "TCP/DTLS/SCTP". Usage of the attribute with other proto values
llowing proto needs to be defined in a separate specification.
values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute </t>
with other </aside>
proto values needs to be defined
in a separate specification.
</t>
</section> </section>
<section title="Syntax" anchor="attr-sctp-port-syn"> <section anchor="attr-sctp-port-syn" numbered="true" toc="default">
<t> <name>Syntax</name>
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number <t>
of this document.] The definition of the SDP "sctp-port" attribute is:
</t> </t>
<t>
The definition of the SDP 'sctp-port' attribute is:
</t>
<figure>
<artwork><![CDATA[
Attribute name: sctp-port <dl>
Type of attribute: media <dt>Attribute name:</dt>
Mux category: CAUTION <dd>sctp-port</dd>
Subject to charset: No
Purpose: Indicate the SCTP port value associated with
the SDP Media Description.
Appropriate values: Integer
Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com
Reference: RFCXXXX
Syntax: <dt>Type of attribute:</dt>
<dd>media</dd>
sctp-port-value = 1*5<DIGIT defined in RFC4566> <dt>Mux category:</dt>
<dd>CAUTION</dd>
The SCTP port range is between 0 and 65535 (both included). <dt>Subject to charset:</dt>
Leading zeroes MUST NOT be used. <dd>No</dd>
Example: <dt>Purpose:</dt>
<dd>Indicate the SCTP port value associated with the SDP media
description.</dd>
a=sctp-port:5000 <dt>Appropriate values:</dt>
<dd>Integer</dd>
<dt>Contact name:</dt>
<dd><t><contact fullname="Christer Holmberg"/></t></dd>
<dt>Contact e-mail:</dt>
<dd>christer.holmberg@ericsson.com</dd>
<dt>Reference:</dt>
<dd>RFC 8841</dd>
<dt>Syntax:</dt>
<dd>
<sourcecode type="abnf">
sctp-port-value = 1*5(DIGIT) ; DIGIT defined in RFC 4566
</sourcecode>
</dd>
</dl>
<t>The SCTP port range is between 0 and 65535 (both included).
Leading zeroes <bcp14>MUST NOT</bcp14> be used.</t>
<t>Example:</t>
<sourcecode type="sdp">
a=sctp-port:5000
</sourcecode>
]]></artwork>
</figure>
</section> </section>
<section title="Mux Category" anchor="attr-sctp-port-mux"> <section anchor="attr-sctp-port-mux" numbered="true" toc="default">
<t> <name>Mux Category</name>
The mux category <xref target="I-D.ietf-mmusic-sdp-mux-attributes" <t>
/> for The mux category <xref target="RFC8859" format="default"/> for
the SDP 'sctp-port' attribute is CAUTION. the SDP "sctp-port" attribute is CAUTION.
</t> </t>
<t> <t>
As the usage of multiple SCTP associations on top of a single As the usage of multiple SCTP associations on top of a single
DTLS association is outside the scope of this specification, DTLS association is outside the scope of this specification,
no mux rules are specified for the 'UDP/DTLS/SCTP' and no mux rules are specified for the "UDP/DTLS/SCTP" and
'TCP/DTLS/SCTP' proto values. Future extensions, that define "TCP/DTLS/SCTP" proto values. Future extensions that define
how to negotiate multiplexing of multiple SCTP associations of top of how to negotiate multiplexing of multiple SCTP associations of top of
a single DTLS association, need to also define the mux rules for t he a single DTLS association need to also define the mux rules for th e
attribute. attribute.
</t> </t>
</section> </section>
</section> </section>
<section anchor="attr-max-message-size" numbered="true" toc="default">
<section title="SDP 'max-message-size' Attribute" anchor="attr-max-message-siz <name>SDP "max-message-size" Attribute</name>
e"> <section anchor="attr-max-message-size-gen" numbered="true" toc="default">
<section title="General" anchor="attr-max-message-size-gen"> <name>General</name>
<t> <t>
This section defines a new SDP media-level attribute, 'max-message This section defines a new SDP media-level attribute, "max-message
-size'. -size".
The attribute can be associated with an m- line to indicate the ma The attribute can be associated with an "m=" line to indicate the
ximum maximum
SCTP user message size (indicated in bytes) that an SCTP endpoint is willing to SCTP user message size (indicated in bytes) that an SCTP endpoint is willing to
receive on the SCTP association associated with the m- line. Diffe rent receive on the SCTP association associated with the "m=" line. Dif ferent
attribute values can be used in each direction. attribute values can be used in each direction.
</t> </t>
<t> <t>
An SCTP endpoint MUST NOT send a SCTP user message with a message An SCTP endpoint <bcp14>MUST NOT</bcp14> send a SCTP user message
size with a message size
that is larger than the maximum size indicated by the peer, as it that is larger than the maximum size indicated by the peer, as it
cannot be assumed that the peer would accept such message. cannot be assumed that the peer would accept such a message.
</t> </t>
<t> <t>
If the SDP 'max-message-size' attribute contains a maximum message If the SDP "max-message-size" attribute contains a maximum message
size size
value of zero, it indicates the SCTP endpoint will handle messages value of zero, it indicates that the SCTP endpoint will handle
of any size, messages of any size,
subject to memory capacity etc. subject to memory capacity, etc.
</t> </t>
<t> <t>
If the SDP 'max-message-size' attribute is not present, the defaul If the SDP "max-message-size" attribute is not present, the defaul
t value is 64K. t value is 64K.
</t> </t>
<t> <aside>
NOTE: This specification only defines the usage of the SDP 'max-me <t>
ssage-size' NOTE: This specification only defines the usage of the SDP "max-me
attribute when associated with an m- line containing one of the fo ssage-size"
llowing proto attribute when associated with an "m=" line containing one of the
values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'. following proto
values: "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP".
Usage of the attribute with other proto values needs to be defined Usage of the attribute with other proto values needs to be defined
in a separate specification. in a separate specification.
</t> </t>
</aside>
</section> </section>
<section title="Syntax" anchor="attr-max-message-size-syn"> <section anchor="attr-max-message-size-syn" numbered="true" toc="default">
<t> <name>Syntax</name>
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number <t>
of this document.] The definition of the SDP "max-message-size" attribute is:
</t> </t>
<t>
The definition of the SDP 'max-message-size' attribute is:
</t>
<figure>
<artwork><![CDATA[
Attribute name: max-message-size <dl>
Type of attribute: media <dt>Attribute name:</dt>
Mux category: CAUTION <dd>max-message-size</dd>
Subject to charset: No
Purpose: Indicate the maximum message size
(indicated in bytes) that an SCTP
endpoint is willing to receive on the
SCTP association associated with the SDP
Media Description.
Appropriate values: Integer
Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com
Reference: RFCXXXX
Syntax: <dt>Type of attribute:</dt>
<dd>media</dd>
max-message-size-value = 1*<DIGIT defined in RFC4566> <dt>Mux category:</dt>
<dd>CAUTION</dd>
Leading zeroes MUST NOT be used. <dt>Subject to charset:</dt>
<dd>No</dd>
Example: <dt>Purpose:</dt>
<dd>Indicate the maximum message size (indicated in bytes) that an SCTP
endpoint is willing to receive on the SCTP association associated with
the SDP media description.</dd>
a=max-message-size:100000 <dt>Appropriate values:</dt>
<dd>Integer</dd>
<dt>Contact name:</dt>
<dd><t><contact fullname="Christer Holmberg"/></t></dd>
<dt>Contact e-mail:</dt>
<dd>christer.holmberg@ericsson.com</dd>
<dt>Reference:</dt>
<dd>RFC 8841</dd>
<dt>Syntax:</dt>
<dd>
<sourcecode type="abnf">
max-message-size-value = 1*DIGIT ; DIGIT defined in RFC 4566
</sourcecode>
</dd>
</dl>
<t>Leading zeroes <bcp14>MUST NOT</bcp14> be used.</t>
<t>Example:</t>
<sourcecode type="sdp">
a=max-message-size:100000
</sourcecode>
]]></artwork>
</figure>
</section> </section>
<section title="Mux Category" anchor="attr-max-message-size-mux"> <section anchor="attr-max-message-size-mux" numbered="true" toc="default">
<t> <name>Mux Category</name>
The mux category for the SDP 'max-message-size' attribute <t>
The mux category for the SDP "max-message-size" attribute
is CAUTION. is CAUTION.
</t> </t>
<t> <t>
As the usage of multiple SCTP associations on top of a single As the usage of multiple SCTP associations on top of a single
DTLS association is outside the scope of this specification, DTLS association is outside the scope of this specification,
no mux rules are specified for the 'UDP/DTLS/SCTP' and no mux rules are specified for the "UDP/DTLS/SCTP" and
'TCP/DTLS/SCTP' proto values. "TCP/DTLS/SCTP" proto values.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec-udp-dtls-sctp" numbered="true" toc="default">
<section title="UDP/DTLS/SCTP Transport Realization" anchor="sec-udp-dtls-sctp <name>UDP/DTLS/SCTP Transport Realization</name>
">
<t> <t>
The UDP/DTLS/SCTP transport is realized as described below: The UDP/DTLS/SCTP transport is realized as described below:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>
SCTP on top of DTLS is realized according to the procedures SCTP on top of DTLS is realized according to the procedures
defined in <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>; a defined in <xref target="RFC8261" format="default"/>; and
nd </li>
</t> <li>
<t>
DTLS on top of UDP is realized according to the procedures in DTLS on top of UDP is realized according to the procedures in
defined in <xref target="RFC6347"/>. defined in <xref target="RFC6347" format="default"/>.
</t> </li>
</list> </ul>
</t> <aside>
<t> <t>
NOTE: While <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/> allows NOTE: While <xref target="RFC8261" format="default"/> allows
multiple SCTP associations on top of a single DTLS association, multiple SCTP associations on top of a single DTLS association,
the procedures in this specification only support the negotiation of a single the procedures in this specification only support the negotiation of a single
SCTP association on top of any given DTLS association. SCTP association on top of any given DTLS association.
</t> </t>
</section> </aside>
<section title="TCP/DTLS/SCTP Transport Realization" anchor="sec-tcp-dtls-sctp </section>
"> <section anchor="sec-tcp-dtls-sctp" numbered="true" toc="default">
<name>TCP/DTLS/SCTP Transport Realization</name>
<t> <t>
The TCP/DTLS/SCTP transport is realized as described below: The TCP/DTLS/SCTP transport is realized as described below:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t>
SCTP on top of DTLS is realized according to the procedures SCTP on top of DTLS is realized according to the procedures
defined in <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>; a defined in <xref target="RFC8261" format="default"/>; and
nd </li>
</t> <li>
<t> DTLS on top of TCP is realized using the framing method defined in
DTLS on top of TCP is realized using the framing method define <xref target="RFC4571" format="default"/>, with DTLS packets being
d in sent and received
<xref target="RFC4571"/>, with DTLS packets being sent and rec instead of RTP/RTCP packets using the shim defined in <xref
eived target="RFC4571" format="default"/>. The length field defined in
instead of RTP/RTCP packets using the shim defined in <xref ta <xref target="RFC4571" format="default"/> precedes each DTLS
rget="RFC4571"/>, message, and SDP signaling is done according to the procedures
so that length field defined in <xref target="RFC4571"/> defined in this specification.
precedes each DTLS message, and SDP signaling according to the </li>
procedures </ul>
defined in this specification. <aside>
</t>
</list>
</t>
<t> <t>
NOTE: TLS on top of TCP, without using the framing method defined in NOTE: TLS on top of TCP, without using the framing method defined in
<xref target="RFC4571"/> is outside the scope of this specification. <xref target="RFC4571" format="default"/>, is outside the scope of thi s specification.
A separate proto value would need to be registered for such transport realization. A separate proto value would need to be registered for such transport realization.
</t> </t>
</section> </aside>
<section title="Association And Connection Management" anchor="sec-con-mgmt"> </section>
<section title="General" anchor="sec-con-mgmt-gen"> <section anchor="sec-con-mgmt" numbered="true" toc="default">
<t> <name>Association and Connection Management</name>
This section describes how to manage an SCTP association, DTLS ass <section anchor="sec-con-mgmt-gen" numbered="true" toc="default">
ociation <name>General</name>
<t>
This section describes how to manage an SCTP association, DTLS ass
ociation,
and TCP connection using SDP attributes. and TCP connection using SDP attributes.
</t> </t>
<t> <t>
The SCTP association, the DTLS association and the TCP connection The SCTP association, the DTLS association, and the TCP
are managed independently connection are managed independently
from each other. Each can be established and closed without impact from each other. Each can be established and closed without impacting
ing others. others.
</t> </t>
<t> <t>
The detailed SDP Offer/Answer <xref target="RFC3264"/> procedures The detailed SDP offer/answer <xref target="RFC3264"
for the SDP attributes format="default"/> procedures for the SDP attributes
are described in <xref target="sec-sdp-oa"/>. are described in <xref target="sec-sdp-oa" format="default"/>.
</t> </t>
</section> </section>
<section title="SDP sendrecv/sendonly/recvonly/inactive Attribute" anchor= <section anchor="sec-con-mgmt-direction" numbered="true" toc="default">
"sec-con-mgmt-direction"> <name>SDP "sendrecv"/"sendonly"/"recvonly"/"inactive" Attributes</name>
<t> <t>
This specification does not define semantics for the SDP direction This specification does not define semantics for the SDP direction
attributes <xref target="RFC4566"/>. Unless semantics of these attributes <xref target="RFC4566" format="default"/>. Unless the seman
attributes for an SCTP association usage have been defined, SDP di tics of these
rection attributes for an SCTP association usage have been defined, SDP direct
attributes MUST be ignored if present. ion
</t> attributes <bcp14>MUST</bcp14> be ignored if present.
</t>
</section> </section>
<section title="SCTP Association" anchor="sec-con-mgmt-sctp"> <section anchor="sec-con-mgmt-sctp" numbered="true" toc="default">
<t> <name>SCTP Association</name>
<t>
When an SCTP association is established, both SCTP endpoints When an SCTP association is established, both SCTP endpoints
MUST initiate the SCTP association (i.e. both SCTP endpoints take <bcp14>MUST</bcp14> initiate the SCTP association (i.e., both
the 'active' SCTP endpoints take the "active"
role), and MUST use the same SCTP port as client port and server p role). In addition, both endpoints <bcp14>MUST</bcp14> use the
ort (in order to same SCTP port as client
prevent two separate SCTP associations from being established). port and server port, in order to
</t> prevent two separate SCTP associations from being established.
<t> </t>
As both SCTP endpoints take the 'active' role, the SDP 'setup' <t>
attribute <xref target="RFC4145"/> does not apply to SCTP associat As both SCTP endpoints take the "active" role, the SDP "setup"
ion attribute <xref target="RFC4145" format="default"/> does not apply to
establishment. However the 'setup' attribute does apply to establi SCTP association
shment establishment. However, the "setup" attribute does apply to establishm
of the underlying DTLS association and TCP connection. ent
</t> of the underlying DTLS association and TCP connection.
<t> </t>
NOTE: The procedure above is different from TCP, where one endpoin <aside>
t takes the 'active' <t>
role, the other endpoint takes the 'passive' role, and only the 'a NOTE: The procedure above is different from TCP, where one endpoint ta
ctive' endpoint initiates kes the "active"
the TCP connection <xref target="RFC4145"/>. role, the other endpoint takes the "passive" role, and only the
</t> "active" endpoint initiates
<t> the TCP connection <xref target="RFC4145" format="default"/>.
NOTE: When the SCTP association is established it is assumed that </t>
any NAT traversal </aside>
procedures for the underlying transport protocol (UDP or TCP) have <aside>
successfully been <t>
performed. NOTE: When the SCTP association is established, it is assumed that any
</t> NAT traversal
<t> procedures for the underlying transport protocol (UDP or TCP) have suc
The SDP 'connection' attribute <xref target="RFC4145"/> does not a cessfully been
pply to the SCTP performed.
association. In order to trigger the closure of an existing SCTP a </t>
ssociation, and </aside>
establishment of a new SCTP association, the SDP 'sctp-port' attri <t>
bute [<xref target="attr-sctp-port"/>] The SDP "connection" attribute <xref target="RFC4145"
is used to indicate a new (different than the ones currently used) format="default"/> does not apply to the SCTP
SCTP port. The existing association. In order to trigger the closure of an existing SCTP assoc
SCTP association is closed, and the new SCTP association is establ iation and
ished, if one or both establishment of a new SCTP association, the SDP "sctp-port"
endpoints signal a new SCTP port. The 'connection' attribute does attribute (<xref target="attr-sctp-port" format="default"/>)
apply to establishment is used to indicate a new (different than the ones currently used)
of underlying TCP connections. SCTP port. The existing
</t> SCTP association is closed, and the new SCTP association is
<t> established, if one or both
Alternatively, an SCTP association can be closed using the SDP 'sc endpoints signal a new SCTP port. The "connection" attribute does
tp-port' attribute apply to establishment
with a zero attribute value. Later, a new SCTP association can be of underlying TCP connections.
established using the </t>
procedures in this section for establishing an SCTP association.
</t> <t>
<t> Alternatively, an SCTP association can be closed using the SDP
SCTP associations might be closed without SDP signalling, e.g, in "sctp-port" attribute with an attribute value of zero. Later, a new SC
case of a failure. TP
The procedures in this section MUST be followed to establish a new association can be established using the procedures in this section
SCTP association. This requires a new SDP Offer/Answer exchange. for establishing an SCTP association.
New (different than the ones currently used) SCTP ports MUST be us </t>
ed by both <t>
endpoints. SCTP associations might be closed without SDP signaling -- for exa
</t> mple,
<t> in case of a failure.
The procedures in this section <bcp14>MUST</bcp14> be followed
to establish a new
SCTP association. This requires a new SDP offer/answer exchange.
New (different than the ones currently used) SCTP ports
<bcp14>MUST</bcp14> be used by both endpoints.
</t>
<aside>
<t>
NOTE: Closing and establishing a new SCTP association using the SD P NOTE: Closing and establishing a new SCTP association using the SD P
'sctp-port' attribute will not affect the state of the underlying "sctp-port" attribute will not affect the state of the underlying
DTLS association. DTLS association.
</t> </t>
</aside>
</section> </section>
<section title="DTLS Association (UDP/DTLS/SCTP And TCP/DTLS/SCTP)" anchor <section anchor="sec-con-mgmt-dtls" numbered="true" toc="default">
="sec-con-mgmt-dtls"> <name>DTLS Association (UDP/DTLS/SCTP and TCP/DTLS/SCTP)</name>
<t> <t>
A DTLS association is managed according to the procedures in <xref targe A DTLS association is managed according to the procedures in <xref
t="I-D.ietf-mmusic-dtls-sdp"/>. target="RFC8842" format="default"/>.
Hence, the SDP 'setup' attribute is used to negotiate the (D)TLS roles ( Hence, the SDP "setup" attribute is used to negotiate the (D)TLS roles
'client' and 'server') ("client" and "server")
<xref target="RFC8122"/>. <xref target="RFC8122" format="default"/>.
</t> </t>
<t> <aside>
NOTE: The SDP 'setup' attribute is used to negotiate both the DTLS roles <t>
and the NOTE: The SDP "setup" attribute is used to negotiate both the DTLS roles
TCP roles (<xref target="sec-con-mgmt-tcp"/>). and the
</t> TCP roles (<xref target="sec-con-mgmt-tcp" format="default"/>).
<t> </t>
NOTE: As described in <xref target="RFC5245"/>, if the Interactive Conne </aside>
ctivity <aside>
Establishment (ICE) mechanism <xref target="RFC5245"/> is used, all ICE <t>
candidates associated with a DTLS association are considered part of the NOTE: As described in <xref target="RFC8445" format="default"/>, if
same DTLS association. the Interactive Connectivity
Thus, a switch from one candidate pair to another candidate pair will no Establishment (ICE) mechanism <xref target="RFC8445"
t trigger the establishment format="default"/> is used, all ICE
of a new DTLS association. candidates associated with a DTLS association are considered part of
</t> the same DTLS association.
Thus, a switch from one candidate pair to another candidate pair
will not trigger the establishment
of a new DTLS association.
</t>
</aside>
</section> </section>
<section title="TCP Connection (TCP/DTLS/SCTP)" anchor="sec-con-mgmt-tcp"> <section anchor="sec-con-mgmt-tcp" numbered="true" toc="default">
<t> <name>TCP Connection (TCP/DTLS/SCTP)</name>
The TCP connection is managed according to the procedures in <xref targe <t>
t="RFC4145"/>. Hence, The TCP connection is managed according to the procedures in <xref
the SDP 'setup' attribute is used to negotiate the TCP roles ('active' a target="RFC4145" format="default"/>. Hence,
nd 'passive'), and the SDP "setup" attribute is used to negotiate the TCP roles ("active"
the SDP 'connection' attribute is used to indicate whether to use an exi and "passive"), and
sting TCP connection, the SDP "connection" attribute is used to indicate whether to use an
or create a new one. The SDP 'setup' attribute 'holdconn' value MUST NOT existing TCP connection
be used. or create a new one. The SDP "setup" attribute "holdconn" value
</t> <bcp14>MUST NOT</bcp14> be used.
<t> </t>
NOTE: A change of the TCP roles will also trigger a closure of the DTLS <aside>
association, and <t>
establishment of a new DTLS association, according to the procedures in NOTE: A change of the TCP roles will also trigger a closure of the
<xref target="I-D.ietf-mmusic-dtls-sdp"/>. DTLS association and
</t> establishment of a new DTLS association, according to the procedures
<t> in <xref target="RFC8842" format="default"/>.
NOTE: As specified in <xref target="I-D.ietf-mmusic-dtls-sdp"/>, usage o </t>
f the SDP 'setup' attribute </aside>
'holdconn' value is not allowed. Therefore this specification also forbi <aside>
ds usage of the attribute <t>
NOTE: As specified in <xref target="RFC8842" format="default"/>, usage
of the SDP "setup" attribute
"holdconn" value is not allowed. Therefore, this specification also
forbids usage of the attribute
value for TCP, as DTLS is transported on top of TCP. value for TCP, as DTLS is transported on top of TCP.
</t> </t>
</aside>
</section> </section>
</section> </section>
<section anchor="sec-sdp-oa" numbered="true" toc="default">
<section title="SDP Offer/Answer Procedures" anchor="sec-sdp-oa"> <name>SDP Offer/Answer Procedures</name>
<section title="General"> <section numbered="true" toc="default">
<t> <name>General</name>
This section defines the SDP Offer/Answer <xref target="RFC3264"/> <t>
This section defines the SDP Offer/Answer <xref target="RFC3264" format=
"default"/>
procedures for negotiating and establishing an SCTP-over-DTLS associatio n. procedures for negotiating and establishing an SCTP-over-DTLS associatio n.
Unless explicitly stated, the procedures apply to both the Unless explicitly stated, the procedures apply to both the
'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' m- line proto values. "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" "m=" line proto values.
</t> </t>
<t> <t>
Each endpoint MUST associate one or more certificate fingerprints, using Each endpoint <bcp14>MUST</bcp14> associate one or more certificate
the SDP 'fingerprint' attribute with the m- line, following the procedur fingerprints using
es the SDP "fingerprint" attribute with the "m=" line, following the
in <xref target="RFC8122"/>. procedures in <xref target="RFC8122" format="default"/>.
</t> </t>
<t> <t>
The authentication certificates are interpreted and validated as The authentication certificates are interpreted and validated as
defined in <xref target="RFC8122"/>. Self-signed defined in <xref target="RFC8122" format="default"/>. Self-signed
certificates can be used securely, provided that the integrity of the certificates can be used securely, provided that the integrity of the
SDP description is assured as defined in <xref target="RFC8122"/>. SDP description is assured, as defined in <xref target="RFC8122"
</t> format="default"/>.
<t> </t>
Each endpoint MUST associate an SDP 'tls-id' attribute with the m- line,
following the procedures in <xref target="I-D.ietf-mmusic-dtls-sdp"/>.
</t>
</section>
<section title="Generating the Initial SDP Offer" anchor="sec-oa-initial-o
ffer">
<t>
When the offerer creates an initial offer, the offerer:
</t>
<t>
<list style="symbols">
<t> <t>
MUST associate an SDP setup attribute with the m- line; Each endpoint <bcp14>MUST</bcp14> associate an SDP "tls-id" attribute
with the "m=" line,
following the procedures in <xref target="RFC8842" format="default"/>.
</t> </t>
</section>
<section anchor="sec-oa-initial-offer" numbered="true" toc="default">
<name>Generating the Initial SDP Offer</name>
<t> <t>
MUST associate an SDP 'sctp-port' attribute with the m- line; When the offerer creates an initial offer, the offerer:
</t> </t>
<ul spacing="normal">
<li>
<bcp14>MUST</bcp14> associate an SDP "setup" attribute with the "m=" l
ine;
</li>
<li>
<bcp14>MUST</bcp14> associate an SDP "sctp-port" attribute with the "m
=" line;
</li>
<li>
<bcp14>MUST</bcp14>, in the case of TCP/DTLS/SCTP, associate an SDP "c
onnection"
attribute, with a "new" attribute value, with the "m=" line; and
</li>
<li>
<bcp14>MAY</bcp14> associate an SDP "max-message-size" attribute
(<xref target="attr-max-message-size" format="default"/>) with the "m="
line.
</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Generating the SDP Answer</name>
<t> <t>
MUST, in the case of TCP/DTLS/SCTP, associate an SDP 'connection' When the answerer receives an offer that contains an "m=" line describ
attribute, with a 'new' attribute value, with the m- line; and ing
an SCTP-over-DTLS association, if the answerer accepts the association
,
the answerer:
</t> </t>
<ul spacing="normal">
<li>
<bcp14>MUST</bcp14> insert a corresponding "m=" line in the
answer, with an "m=" line
proto value <xref target="RFC3264" format="default"/> identical to t
he value in
the offer;
</li>
<li>
<bcp14>MUST</bcp14> associate an SDP "setup" attribute with the "m="
line;
</li>
<li>
<bcp14>MUST</bcp14> associate an SDP "sctp-port" attribute with
the "m=" line. If the
offer contained a new (different than the one currently used) SCTP
port value, the answerer <bcp14>MUST</bcp14> also associate a new
SCTP port value. If
the offer contained a zero SCTP port value, or if the answerer does
not
accept the SCTP association, the answerer <bcp14>MUST</bcp14> also a
ssociate a zero
SCTP port value; and
</li>
<li>
<bcp14>MAY</bcp14> associate an SDP "max-message-size" attribute
(<xref target="attr-max-message-size" format="default"/>) with the "
m=" line. The
attribute value in the answer is independent of the value
(if present) in the corresponding "m=" line of the offer.
</li>
</ul>
<t> <t>
MAY associate an SDP 'max-message-size' attribute Once the answerer has sent the answer:
[<xref target="attr-max-message-size" />] with the m- line.
</t> </t>
</list> <ul spacing="normal">
</t> <li>
</section> in the case of TCP/DTLS/SCTP, if a TCP connection has not yet
<section title="Generating the SDP Answer"> been established or an existing TCP connection is to be
<t> closed and replaced by a new one, the answerer
When the answerer receives an offer, which contains an m- line d <bcp14>MUST</bcp14> follow the procedures
escribing in <xref target="RFC4145" format="default"/> for closing and
an SCTP-over-DTLS association, if the answerer accepts the assoc establishing a TCP connection;
iation, </li>
the answerer: <li>
</t> if a DTLS association has not yet been established or
<t>
<list style="symbols">
<t>
MUST insert a corresponding m- line in the answer, with
an m- line
proto value <xref target="RFC3264"/> identical to the va
lue in
the offer;
</t>
<t>
MUST associate an SDP 'setup' attribute with the m- line
;
</t>
<t>
MUST associate an SDP 'sctp-port' attribute with the m-
line. If the
offer contained a new (different than the one currently
used) SCTP
port value the answerer MUST also associate a new SCTP p
ort value. If
the offer contained a zero SCTP port value, or if the an
swerer does not
accept the SCTP association, the answerer MUST also asso
ciate a zero
SCTP port value; and
</t>
<t>
MAY associate an SDP 'max-message-size' attribute
[<xref target="attr-max-message-size" />] with the m- li
ne. The
attribute value in the answer is independent from the va
lue
(if present) in the corresponding m- line of the offer.
</t>
</list>
</t>
<t>
Once the answerer has sent the answer the answerer:
</t>
<t>
<list style="symbols">
<t>
MUST, in the case of TCP/DTLS/SCTP, if a TCP connection has not yet
been established, or if an existing TCP connection is to be
closed and replaced by a new TCP connection, follow the procedures
in <xref target="RFC4145"/> for closing and establishing a TCP conne
ction;
</t>
<t>
MUST, if a DTLS association has not yet been established, or if
an existing DTLS association is to be closed and replaced by a an existing DTLS association is to be closed and replaced by a
new DTLS association, follow the procedures in <xref target="I-D.iet new one, the answerer <bcp14>MUST</bcp14> follow the
f-mmusic-dtls-sdp"/> procedures in <xref target="RFC8842" format="default"/>
for closing the currently used, and establishing a new, DTLS associa for closing the currently used DTLS association and establishing a
tion; and new one; and
</t> </li>
<t> <li>
MUST, if an SCTP association has not yet been established, or if an if an SCTP association has not yet been established or an
existing SCTP association is to be closed and replaced by a new existing SCTP association is to be closed and replaced by a new
SCTP association, initiate the closing of the existing one, the answerer <bcp14>MUST</bcp14> initiate the
SCTP association (if applicable) and establishment of the SCTP assoc closing of the existing
iation. SCTP association (if applicable) and establishment of the new
</t> association.
</list> </li>
</t> </ul>
<t> <t>
If the SDP 'sctp-port' attribute in the answer contains a zero attribute If the SDP "sctp-port" attribute in the answer contains an attribute
value, the answerer MUST NOT establish an SCTP association. If an SCTP value of zero, the answerer <bcp14>MUST NOT</bcp14> establish an SCTP as
association exists, the offerer MUST close it. sociation. If an SCTP
</t> association exists, the offerer <bcp14>MUST</bcp14> close it.
<t> </t>
If the answerer does not accept the m- line in the offer, it MUST assign <t>
a zero port value to the corresponding m- line in the answer, following If the answerer does not accept the "m=" line in the offer, it <bcp14>MU
the ST</bcp14> assign
procedures in <xref target="RFC3264"/>. In addition, the answerer MUST N a zero port value to the corresponding "m=" line in the answer, followin
OT g the
initiate the establishment of a TCP connection, a DTLS association or a procedures in <xref target="RFC3264" format="default"/>. In addition,
DTLS association associated with the m- line. the answerer <bcp14>MUST NOT</bcp14>
</t> initiate the establishment of a TCP connection, a DTLS association, or a
DTLS association associated with the "m=" line.
</t>
</section> </section>
<section title="Offerer Processing of the SDP Answer"> <section numbered="true" toc="default">
<t> <name>Offerer Processing of the SDP Answer</name>
Once the offerer has received the answer the offerer: <t>
</t> Once the offerer has received the answer:
<t> </t>
<list style="symbols"> <ul spacing="normal">
<t> <li>
MUST, in the case of TCP/DTLS/SCTP, if a TCP connection has not yet in the case of TCP/DTLS/SCTP, if a TCP connection has not yet
been established, or if an existing TCP connection is to be been established or an existing TCP connection is to be
closed and replaced by a new TCP connection, follow the procedures closed and replaced by a new one, the offerer <bcp14>MUST</bcp14>
in <xref target="RFC4145"/> for closing and establishing a TCP conne follow the procedures
ction; in <xref target="RFC4145" format="default"/> for closing and
</t> establishing a TCP connection;
<t> </li>
MUST, if a DTLS association has not yet been established, or if <li>
if a DTLS association has not yet been established or
an existing DTLS association is to be closed and replaced by a an existing DTLS association is to be closed and replaced by a
new DTLS association, follow the procedures in <xref target="I-D.iet new one, the offerer <bcp14>MUST</bcp14> follow the procedures in
f-mmusic-dtls-sdp"/> <xref target="RFC8842" format="default"/>
for closing and establishing a DTLS association; and for closing and establishing a DTLS association; and
</t> </li>
<t> <li>
MUST, if an SCTP association has not yet been established, or if an if an SCTP association has not yet been established or an
existing SCTP association is to be closed and replaced by a new existing SCTP association is to be closed and replaced by a new
SCTP association, initiate the closing of the existing one, the offerer <bcp14>MUST</bcp14> initiate the closing of the
SCTP association (if applicable) and establishment of the SCTP assoc existing SCTP association (if applicable) and establishment of the
iation. new association.
</t> </li>
</list> </ul>
</t> <t>
<t> If the SDP "sctp-port" attribute in the answer contains an attribute
If the SDP 'sctp-port' attribute in the answer contains a zero attribute value of zero, the offerer <bcp14>MUST NOT</bcp14> establish an SCTP
value, the offerer MUST NOT establish an SCTP association. If an SCTP association. If, in addition, an SCTP
association exists in that case, the offerer MUST close it. association exists, the offerer <bcp14>MUST</bcp14> close it.
</t> </t>
<t> <t>
If the m- line in the answer contains a zero port value, the offerer If the "m=" line in the answer contains a zero port value, the offerer
MUST NOT initiate the establishment a TCP connection, a DTLS association <bcp14>MUST NOT</bcp14> initiate the establishment of a TCP
or an SCTP association associated with the m- line. If a TCP connection, connection, a DTLS association,
or a DTLS association or an SCTP association exists in that case, the of or an SCTP association associated with the "m=" line. If, in addition,
ferer MUST close it. a TCP connection,
</t> DTLS association, or SCTP association exists, the
offerer <bcp14>MUST</bcp14> close it.
</t>
</section> </section>
<section title="Modifying the Session"> <section numbered="true" toc="default">
<t> <name>Modifying the Session</name>
<t>
When an offerer sends an updated offer, in order to modify a previously established When an offerer sends an updated offer, in order to modify a previously established
SCTP association, it follows the procedures in <xref target="sec-oa-init SCTP association, it follows the procedures in <xref
ial-offer" />, target="sec-oa-initial-offer" format="default"/>,
with the following exceptions: with the following exceptions:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>
<t> If the offerer wants to close an SCTP association and immediately
If the offerer wants to close an SCTP association, and immediately e establish a new SCTP association,
stablish a new SCTP association, it <bcp14>MUST</bcp14> associate an SDP "sctp-port"
the offerer MUST associate an SDP 'sctp-port' attribute with a new ( attribute with a new (different than the
different than the
one currently used) attribute value. This will not impact the underl ying one currently used) attribute value. This will not impact the underl ying
DTLS association (and TCP connection in case of TCP/DTLS/SCTP). DTLS association (or TCP connection, in the case of TCP/DTLS/SCTP).
</t> </li>
<t> <li>
If the offerer wants to close an SCTP association, without immediate If the offerer wants to close an SCTP association without
ly establishing a new immediately establishing a new
SCTP association, the offerer MUST associate an SDP 'sctp-port' attr SCTP association, it <bcp14>MUST</bcp14> associate an SDP
ibute with a zero attribute "sctp-port" attribute with an attribute
value. This will not impact the underlying DTLS association (and TCP value of zero. This will not impact the underlying DTLS association
connection (or
in case of TCP/DTLS/SCTP). TCP connection, in the case of TCP/DTLS/SCTP).
</t> </li>
<t> <li>
If the offerer wants to establish an SCTP association, and another S If the offerer wants to establish an SCTP association, and another
CTP association SCTP association
was previously closed, the offerer MUST associate an SDP 'sctp-port' was previously closed, the offerer <bcp14>MUST</bcp14> associate
attribute with an SDP "sctp-port" attribute with
a new attribute value (different than the value associated with the a new attribute value (different than the value associated with
previous SCTP association). the previous SCTP association).
If the previous SCTP association was closed successfully following u If the previous SCTP association was closed successfully following
se of an SDP 'sctp-port' attribute with a zero use of an SDP "sctp-port" attribute with an
attribute value, the offerer MAY use the same attribute value for th attribute value of zero, the offerer <bcp14>MAY</bcp14> use the same
e new SCTP association attribute value for the new SCTP association
that was used with the previous SCTP association before it was close that was used with the previous SCTP association before it was
d. This will not impact closed. This will not impact
the underlying DTLS association (and TCP connection in case of TCP/D the underlying DTLS association (or TCP connection, in the case of
TLS/SCTP). TCP/DTLS/SCTP).
</t> </li>
<t> <li>
If the offerer wants to close an existing SCTP association, and the If the offerer wants to close an existing SCTP association and the
underlying DTLS association (and the underlying TCP connection in ca underlying DTLS association (and the underlying TCP connection, in
se of the case of TCP/DTLS/SCTP), it <bcp14>MUST</bcp14> assign a zero port
TCP/DTLS/SCTP) it MUST assign a zero port value to the m- line assoc value to
iated with the the "m=" line associated with the
SCTP and DTLS associations (and TCP connection in case of TCP/DTLS/S SCTP and DTLS associations (and TCP connection, in the case of TCP/D
CTP), TLS/SCTP),
following the procedures in <xref target="RFC3264"/>. following the procedures in <xref target="RFC3264" format="default"/
</t> >.
<t> </li>
<li>
NOTE: This specification does not define a mechanism for explicitly closing a DTLS NOTE: This specification does not define a mechanism for explicitly closing a DTLS
association while maintaining the overlying SCTP association. Howeve r, if a DTLS association while maintaining the overlying SCTP association. Howeve r, if a DTLS
association is closed and replaced with a new DTLS association, as a association is closed and replaced with a new DTLS association as
result of some other action a result of some other action
<xref target="I-D.ietf-mmusic-dtls-sdp"/>, the state of the SCTP ass <xref target="RFC8842" format="default"/>, the state of the SCTP
ociation is not affected. association is not affected.
</t> </li>
</list> </ul>
</t>
<t> <t>
The offer follows the procedures in <xref target="I-D.ietf-mmusic-dtls-s The offerer follows the procedures in <xref target="RFC8842"
dp"/> regarding format="default"/> regarding the DTLS association impacts when
the DTLS association impacts when modifying a session. modifying a session.
</t> </t>
<t> <t>
In the case of TCP/DTLS/SCTP, the offerer follows the procedures in In the case of TCP/DTLS/SCTP, the offerer follows the procedures in
<xref target="RFC4145"/> regarding the TCP connection impacts when <xref target="RFC4145" format="default"/> regarding the TCP connection i mpacts when
modifying a session. modifying a session.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Multihoming Considerations"> <name>Multihoming Considerations</name>
<t> <t>
Multihoming is not supported when sending SCTP on top of DTLS, Multihoming is not supported when sending SCTP on top of DTLS,
as DTLS does not expose address management of the underlying as DTLS does not expose address management of the underlying
transport protocols (UDP or TCP) to its upper layer. transport protocols (UDP or TCP) to its upper layer.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="NAT Considerations"> <name>NAT Considerations</name>
<section title="General"> <section numbered="true" toc="default">
<t> <name>General</name>
When SCTP-over-DTLS is used in NAT environment, it relies on the N <t>
AT When SCTP-over-DTLS is used in a NAT environment, it relies on the
NAT
traversal procedures for the underlying transport protocol (UDP or TCP). traversal procedures for the underlying transport protocol (UDP or TCP).
</t> </t>
</section> </section>
<section title="ICE Considerations"> <section numbered="true" toc="default">
<t> <name>ICE Considerations</name>
When SCTP-over-DTLS is used with UDP based ICE candidates <xref ta <t>
rget="RFC5245"/> When SCTP-over-DTLS is used with UDP-based ICE candidates <xref
then the procedures for UDP/DTLS/SCTP [<xref target="sec-udp-dtls- target="RFC8445" format="default"/>,
sctp"/>] are used. then the procedures for UDP/DTLS/SCTP (<xref
</t> target="sec-udp-dtls-sctp" format="default"/>) are used.
<t> </t>
When SCTP-over-DTLS is used with TCP based ICE candidates <xref ta <t>
rget="RFC6544"/> When SCTP-over-DTLS is used with TCP-based ICE candidates <xref
then the procedures for TCP/DTLS/SCTP [<xref target="sec-tcp-dtls- target="RFC6544" format="default"/>,
sctp"/>] are used. then the procedures for TCP/DTLS/SCTP (<xref
</t> target="sec-tcp-dtls-sctp" format="default"/>) are used.
<t> </t>
<t>
In ICE environments, during the nomination process, endpoints go t hrough multiple In ICE environments, during the nomination process, endpoints go t hrough multiple
ICE candidate pairs, until the most preferred candidate pair is fo und. During ICE candidate pairs until the most preferred candidate pair is fou nd. During
the nomination process, data can be sent as soon as the first work ing candidate the nomination process, data can be sent as soon as the first work ing candidate
pair is found, but the nomination process still continues and sele pair is found, but the nomination process still continues, and
cted candidate pairs selected candidate pairs
can still change while data is sent. Furthermore, if endpoints roa can still change while data is sent. Furthermore, if endpoints
m between networks, roam between networks -- for instance, when a mobile endpoint switc
for instance when mobile endpoint switches from mobile connection hes from mobile
to WiFi, endpoints will connection to WiFi -- endpoints will
initiate an ICE restart, which will trigger a new nomination proce initiate an ICE restart. This will trigger a new nomination
ss between the new set process between the new set
of candidates and likely result in the new nominated candidate pai of candidates, which will likely result in the new nominated candi
r. date pair.
</t> </t>
<t> <t>
Implementations MUST treat all ICE candidate pairs associated with Implementations <bcp14>MUST</bcp14> treat all ICE candidate pairs
associated with
an SCTP association on top of a DTLS association as part of the sa me an SCTP association on top of a DTLS association as part of the sa me
DTLS association. Thus, there will only be one SCTP handshake and one DTLS DTLS association. Thus, there will only be one SCTP handshake and one DTLS
handshake even if there are multiple valid candidate pairs, and sh handshake even if there are multiple valid candidate pairs;
ifting from one candidate shifting from one candidate
pair to another, including switching between UDP to TCP candidate pair to another, including switching between UDP and TCP
pairs, will not impact candidate pairs, will not impact
the SCTP or DTLS associations. If new candidates are added, they w the SCTP or DTLS associations. If new candidates are added, they
ill also be part of the will also be part of the
same SCTP and DTLS associations. When transitioning between candid same SCTP and DTLS associations. When transitioning between
ate pairs, different candidate pairs, different
candidate pairs can be currently active in different directions an candidate pairs can be currently active in different directions,
d implementations MUST and implementations <bcp14>MUST</bcp14>
be ready to receive data on any of the candidates, even if this me be ready to receive data on any of the candidates, even if this
ans sending and receiving means sending and receiving
data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at the same time in dif data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at the same time in
ferent directions. different directions.
</t> </t>
<t> <t>
In order to maximize the likelihood of interoperability between th e endpoints, all In order to maximize the likelihood of interoperability between th e endpoints, all
ICE enabled SCTP-over-DTLS endpoints SHOULD implement support for ICE-enabled SCTP-over-DTLS endpoints <bcp14>SHOULD</bcp14>
UDP/DTLS/SCTP. implement support for UDP/DTLS/SCTP.
</t> </t>
<t> <t>
When an SDP offer or answer is sent with multiple ICE candidates d When an SDP offer or answer is sent with multiple ICE candidates
uring initial connection during initial connection
negotiation or after ICE restart, UDP based candidates SHOULD be i negotiation or after ICE restart, UDP-based candidates
ncluded and default <bcp14>SHOULD</bcp14> be included, and the default
candidate SHOULD be chosen from one of those UDP candidates. The p candidate <bcp14>SHOULD</bcp14> be chosen from one of those UDP
roto value MUST match candidates. The proto value <bcp14>MUST</bcp14> match
the transport protocol associated with the default candidate. If U DP transport is used the transport protocol associated with the default candidate. If U DP transport is used
for the default candidate, then 'UDP/DTLS/SCTP' proto value MUST b for the default candidate, then the "UDP/DTLS/SCTP" proto value
e used. If TCP transport <bcp14>MUST</bcp14> be used. If TCP transport
is used for the default candidate, then 'TCP/DTLS/SCTP' proto valu is used for the default candidate, then the "TCP/DTLS/SCTP" proto
e MUST be used. value <bcp14>MUST</bcp14> be used.
Note that under normal circumstances the proto value for offers an Note that under normal circumstances, the proto value for offers
d answers sent during ICE and answers sent during ICE
nomination SHOULD be 'UDP/DTLS/SCTP'. nomination <bcp14>SHOULD</bcp14> be "UDP/DTLS/SCTP".
</t> </t>
<t> <t>
When a subsequent SDP offer or answer is sent after ICE nomination When a subsequent SDP offer or answer is sent after ICE
is complete, and does not nomination is complete, and it does not
initiate ICE restart, it will contain only the nominated ICE candi date pair. initiate ICE restart, it will contain only the nominated ICE candi date pair.
In this case, the proto value MUST match the transport protocol as In this case, the proto value <bcp14>MUST</bcp14> match the
sociated with the transport protocol associated with the
nominated ICE candidate pair. If UDP transport is used for the nom inated pair, nominated ICE candidate pair. If UDP transport is used for the nom inated pair,
then 'UDP/DTLS/SCTP' proto value MUST be used. If TCP transport is then the "UDP/DTLS/SCTP" proto value <bcp14>MUST</bcp14> be
used for the used. If TCP transport is used for the
nominated pair, then 'TCP/DTLS/SCTP' proto value MUST be used. Ple nominated pair, then the "TCP/DTLS/SCTP" proto value
ase note that if an endpoint <bcp14>MUST</bcp14> be used. Please note that if an endpoint
switches between TCP-based and UDP-based candidates during the nom switches between TCP-based and UDP-based candidates during the
ination process the endpoint nomination process, the endpoint
is not required to send an SDP offer for the sole purpose of keepi is not required to send an SDP offer for the sole purpose of
ng the proto value of the keeping the proto value of the
associated m- line in sync. associated "m=" line in sync.
</t> </t>
<t> <aside>
NOTE: The text in the paragraph above only applies when the usage <t>
of ICE NOTE: The text in the paragraph above only applies when the usage of I
has been negotiated. If ICE is not used, the proto value MUST alwa CE
ys reflect has been negotiated. If ICE is not used, the proto value
the transport protocol used at any given time. <bcp14>MUST</bcp14> always reflect
</t> the transport protocol used at any given time.
</t>
</aside>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Examples"> <name>Examples</name>
<section title="Establishment of UDP/DTLS/SCTP association"> <section numbered="true" toc="default">
<figure> <name>Establishment of UDP/DTLS/SCTP Association</name>
<artwork><![CDATA[
SDP Offer:
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:DB8::A8FD
a=tls-id:abc3de65cddef001be82
a=setup:actpass
a=sctp-port:5000
a=max-message-size:100000
- The offerer indicates that the usage of the <t>SDP Offer:</t>
<sourcecode type="sdp">
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:DB8::A8FD
a=tls-id:abc3de65cddef001be82
a=setup:actpass
a=fingerprint:SHA-256 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=sctp-port:5000
a=max-message-size:100000
</sourcecode>
<ul>
<li>The offerer indicates that the usage of the
UDP/DTLS/SCTP association will be as defined UDP/DTLS/SCTP association will be as defined
for the 'webrtc-datachannel' format value. for the "webrtc-datachannel" format value.</li>
- The offerer UDP port value is 54111. <li>The offerer UDP port value is 54111.</li>
- The offerer SCTP port value is 5000. <li>The offerer SCTP port value is 5000.</li>
- The offerer indicates that it can take either the <li>The offerer indicates that it can take either the
client or the server DTLS role. client or the server DTLS role.</li>
</ul>
SDP Answer: <t>
SDP Answer:</t>
<sourcecode type="sdp">
m=application 64300 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP6 2001:DB8::001D
a=tls-id:dbc8de77cddef001be90
a=setup:passive
a=fingerprint:SHA-256 \
3F:82:18:3B:49:6B:19:E5:7C:AB:4A:AD:B9:B1:12:DF:3E:5D:12:DF:54:02: \
49:6B:3E:5D:7C:AB:19:E5:AD:4A
a=sctp-port:6000
a=max-message-size:100000
</sourcecode>
m=application 64300 UDP/DTLS/SCTP webrtc-datachannel <t>
c=IN IP6 2001:DB8::001D Note that due to RFC formatting conventions, this document splits SDP
a=tls-id:dbc8de77cddef001be90 across lines whose content would exceed 72 characters. A backslash
a=setup:passive character marks where this line folding has taken place. This backslash and
a=sctp-port:6000 its trailing CRLF and whitespace would not appear in actual SDP
a=max-message-size:100000 content.</t>
- The answerer UDP port value is 64300. <ul>
- The answerer SCTP port value is 6000. <li>The answerer UDP port value is 64300.</li>
- The answerer takes the server DTLS role. <li>The answerer SCTP port value is 6000.</li>
<li>The answerer takes the server DTLS role.</li>
</ul>
]]></artwork>
</figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
<xref target="RFC4566"/> defines general SDP security considerations, <xref target="RFC4566" format="default"/> defines general SDP
while security considerations, while
<xref target="RFC3264"/>, <xref target="RFC4145"/> and <xref target="R <xref target="RFC3264" format="default"/>, <xref target="RFC4145"
FC8122"/> format="default"/>, and <xref target="RFC8122" format="default"/>
define security considerations when using the SDP offer/answer mechani sm define security considerations when using the SDP offer/answer mechani sm
to negotiate media streams. to negotiate media streams.
</t> </t>
<t> <t>
<xref target="RFC4960"/> defines general SCTP security considerations <xref target="RFC4960" format="default"/> defines general SCTP securit
and <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/> defines security y considerations,
and <xref target="RFC8261" format="default"/> defines security
considerations when using SCTP on top of DTLS. considerations when using SCTP on top of DTLS.
</t> </t>
<t> <t>
This specification does not introduce new security considerations in a ddition This specification does not introduce new security considerations in a ddition
to those defined in the specifications listed above. to those defined in the specifications listed above.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations"> <section anchor="iana-sdp-proto" toc="default" numbered="true">
<section title="New SDP proto values" anchor="iana-sdp-proto" toc="default <name>New SDP Proto Values</name>
"> <t>
<t> This document updates the "Session Description Protocol (SDP)
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of th Parameters" registry,
is document.] following the procedures in <xref target="RFC4566" format="default
</t> "/>,
<t>
This document updates the "Session Description Protocol (SDP) Para
meters" registry,
following the procedures in <xref target="RFC4566" pageno="false"
format="default"/>,
by adding the following values to the table in the SDP "proto" fie ld registry: by adding the following values to the table in the SDP "proto" fie ld registry:
</t> </t>
<texttable anchor="table_SDP_proto_values" title='SDP "proto" field va <table anchor="table_SDP_proto_values" align="center">
lues'> <name>SDP "proto" Field Values</name>
<ttcol align='center'>Type</ttcol> <thead>
<ttcol align='center'>SDP Name</ttcol> <tr>
<ttcol align='center'>Reference</ttcol> <th align="center">Type</th>
<c>proto</c> <th align="center">SDP Name</th>
<c>UDP/DTLS/SCTP</c> <th align="center">Reference</th>
<c>[RFCXXXX]</c> </tr>
<c>proto</c> </thead>
<c>TCP/DTLS/SCTP</c> <tbody>
<c>[RFCXXXX]</c> <tr>
</texttable> <td align="center">proto</td>
</section> <td align="center">UDP/DTLS/SCTP</td>
<td align="center">RFC 8841</td>
<section title="New SDP Attributes" anchor="iana-sdp-attr" toc="default"> </tr>
<section title="sctp-port" anchor="iana-sdp-attr-sctp-port" toc="defau <tr>
lt"> <td align="center">proto</td>
<t> <td align="center">TCP/DTLS/SCTP</td>
This document defines a new SDP media-level attribute,'sctp-po <td align="center">RFC 8841</td>
rt'. The </tr>
details of the attribute are defined in <xref target="attr-sct </tbody>
p-port-syn" </table>
pageno="false" format="default"/>.
</t>
</section>
<section title="max-message-size" anchor="iana-sdp-attr-max-msg-size"
toc="default">
<t>
This document defines a new SDP media-level attribute,'max-mes
sage-size'. The
details of the attribute are defined in <xref target="attr-max
-message-size-syn"
pageno="false" format="default"/>.
</t>
</section>
</section> </section>
<section anchor="iana-sdp-attr" toc="default" numbered="true">
<section title="association-usage Name Registry" anchor="iana-assusage-reg <name>New SDP Attributes</name>
istry" toc="default"> <section anchor="iana-sdp-attr-sctp-port" toc="default" numbered="true">
<name>sctp-port</name>
<t> <t>
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of th This document defines a new SDP media-level attribute,"sctp-po
is document.] rt". The
details of the attribute are defined in <xref
target="attr-sctp-port-syn" format="default"/>.
</t> </t>
</section>
<section anchor="iana-sdp-attr-max-msg-size" toc="default" numbered="tru
e">
<name>max-message-size</name>
<t> <t>
This specification creates a new IANA registry, following the proc This document defines a new SDP media-level
edures in attribute,"max-message-size". The details of the attribute
<xref target="RFC5226"/>, for the namespace associated with the are defined in <xref target="attr-max-message-size-syn"
'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol identifiers. format="default"/>.
</t>
</section>
</section>
<section anchor="iana-assusage-registry" toc="default" numbered="true">
<name>association-usage Name Registry</name>
<t>
Per this specification, a new IANA registry has been created, foll
owing the procedures in
<xref target="RFC8126" format="default"/>, for the namespace assoc
iated with the
"UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" protocol identifiers.
Each fmt value describes the usage of an entire SCTP association, including Each fmt value describes the usage of an entire SCTP association, including
all SCTP streams associated with the SCTP association. all SCTP streams associated with the SCTP association.
</t> </t>
<t>
NOTE: Usage indication of individual SCTP streams is outside the s <aside>
cope of this <t>NOTE: Usage indication of individual SCTP streams is outside th
specification. e scope of this
</t> specification.</t>
<t> </aside>
The fmt value, "association-usage", used with these "proto" values
is required. <t>
It is defined in <xref target="m-line"/>. The fmt value "association-usage" used with these "proto" values is re
</t> quired.
<t> It is defined in <xref target="m-line" format="default"/>.
</t>
<t>
As part of this registry, IANA maintains the following information : As part of this registry, IANA maintains the following information :
</t> </t>
<t>
<list style='hanging'> <dl newline="false" spacing="normal">
<t hangText="association-usage name:">The identifier of the <dt>association-usage name:</dt>
subprotocol, as will be used as the fmt value.</t> <dd>The identifier of the subprotocol, as will be used as the fmt valu
<t hangText="association-usage reference:">A reference to the e.</dd>
document in which the association-usage is defined.</t> <dt>association-usage reference:</dt>
</list> <dd>A reference to the document in which the association-usage is
</t> defined.</dd>
<t> </dl>
<t>
association-usage names are to be subject to the "First Come First Served" association-usage names are to be subject to the "First Come First Served"
IANA registration policy [RFC5226]. IANA registration policy <xref target="RFC8126" format="default" /
</t> >.
<t> </t>
IANA is asked to add initial values to the registry. <t>
</t> IANA has added the following initial values to the registry.
<figure anchor="exempleIANA" title=""> </t>
<artwork><![CDATA[
|----------------------------------------------------------| <table anchor="IANA">
| name | Reference | <name>IANA Initial Values</name>
|----------------------------------------------------------| <thead>
| webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx, | <tr>
| | RFCXXX | <th>Name</th>
|----------------------------------------------------------| <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>webrtc-datachannel</td>
<td>RFC 8832, RFC 8841</td>
</tr>
<tr>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<!--
<t>
[RFC EDITOR NOTE: Please hold the publication of this draft [RFC EDITOR NOTE: Please hold the publication of this draft
until draft-ietf-rtcweb-data-protocol has been published as an RFC. until draft-ietf-rtcweb-data-protocol has been published as an RFC.
Then, replace the reference to draft-ietf-rtcweb-data-protocol Then, replace the reference to draft-ietf-rtcweb-data-protocol
with the RFC number.] with the RFC number.]
</t>
-->
</section>
</section>
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number </middle>
of this document.] <back>
]]></artwork> <references>
</figure> <name>References</name>
</section> <references>
</section> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.0793.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3264.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4145.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4566.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4571.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4960.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6544.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8122.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8261.xml"/>
<section title="Acknowledgments"> <!-- draft-ietf-mmusic-dtls-sdp (RFC 8842) -->
<t> <reference anchor="RFC8842" target="https://www.rfc-editor.org/info/rfc8842">
The authors wish to thank Harald Alvestrand, Randell Jesup, Paul Kyziv
at,
Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen and Ari K
eranen for
their comments and useful feedback. Ben Campbell provided comments as
part
of his AD review. Brian Carpenter performed the Gen-ART review.
</t>
</section>
<section title=""> <front>
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t> <title>Session Description Protocol (SDP) Offer/Answer Considerations for
<t>Changes from draft-ietf-mmusic-sctp-sdp-25 Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)</tit
<list style="symbols"> le>
<t>SDP 'dtls-id' attribute re-named to 'tls-id'.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-24
<list style="symbols">
<t>Minor editorial fix by Roman.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-23
<list style="symbols">
<t>Changes based on IESG review.</t>
<t>- Proto value clarifications.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-22
<list style="symbols">
<t>Changes based on Gen-ART review by Brian Carpenter.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-21
<list style="symbols">
<t>Changes based on AD review by Ben Campbell.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-20
<list style="symbols">
<t>Informative reference to draft-ietf-rtcweb-data-protocol added.
</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-19
<list style="symbols">
<t>Changes based on WG chair comments from Flemming Andreasen.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-18
<list style="symbols">
<t>Changes based on WGLC comments from Paul Kyzivat.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-17
<list style="symbols">
<t>Removal of 'SCTP'.</t>
<t>Document title changed.</t>
<t>Disallow usage of SDP 'setup' attribute 'holdconn' value.</t>
<t>Roman Shpount added as co-editor.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-15
<list style="symbols">
<t>Chapter about SCTP, DTLS and TCP association/connection managem
ent modified.</t>
<t>Removal of SCTP/DTLS.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-14
<list style="symbols">
<t>Changes based on WGLC comments from Magnus Westerlund.</t>
<t>- ABNF clarification that token and port are defined in RFC4566
.</t>
<t>- Specify 40 as maximum digit character length for the SDP max-
message-size value.</t>
<t>- Editorial clarification.</t>
<t>Changes based on discussions at IETF#92.</t>
<t>- Specify that all ICE candidate pairs belong to the same DTLS
association.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-13
<list style="symbols">
<t>Changes based on comments from Paul Kyzivat.</t>
<t>- Text preventing usage of well-known ports removed.</t>
<t>- Editorial clarification.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-12
<list style="symbols">
<t>Mux category rules added for new SDP attributes.</t>
<t>Reference to draft-ietf-mmusic-sdp-mux-attributes added.</t>
<t>Changes based on comments from Roman Shpount:</t>
<t>- Specify that fingerprint or setup roles must not be modified,
unless underlying transport protocol is also modified.</t>
<t>Changes based on comments from Ari Keranen:</t>
<t>- Editorial corrections.</t>
<t>Changes based on comments from Flemming Andreasen:</t>
<t>- Clarify that, if UDP/DTLS/SCTP or TCP/DTLS/SCTP is used,
the DTLS association is established before the SCTP associatio
n.</t>
<t>- Clarify that max-message-size value is given in bytes, and
that different values can be used per direction.</t>
<t>- Section on fmtp attribute removed.</t>
<t>- Editorial corrections.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-11
<list style="symbols">
<t>Example added.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-10
<list style="symbols">
<t>SDP max-message-size attribute added to IANA considerations.</t
>
<t>Changes based on comments from Paul Kyzivat:</t>
<t>- Text about max message size removed from fmtp attribute secti
on.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-09
<list style="symbols">
<t>'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'</t>
<t>Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP trans
ports added.</t>
</list>
</t>
<t>Changes from draft-ietf-mmusic-sctp-sdp-08
<list style="symbols">
<t>Default SCTP port removed:</t>
<t>- Usage of SDP sctp-port attribute mandatory.</t>
<t>SDP max-message-size attribute defined:</t>
<t>- Attribute definition.</t>
<t>- SDP Offer/Answer procedures.</t>
<t>Text about SDP direction attributes added.</t>
<t>Text about TLS role determination added.</t>
</list>
</t>
</section>
</middle>
<back> <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<references title="Normative References"> <organization />
<?rfc include="reference.RFC.0793"?> </author>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3264"?> <author initials="R." surname="Shpount" fullname="Roman Shpount">
<?rfc include="reference.RFC.4145"?> <organization />
<?rfc include="reference.RFC.4566"?> </author>
<?rfc include="reference.RFC.4571"?>
<?rfc include="reference.RFC.4960"?> <date month="January" year="2021" />
<?rfc include="reference.RFC.5226"?> </front>
<?rfc include="reference.RFC.6347"?> <seriesInfo name="RFC" value="8842" />
<?rfc include="reference.RFC.6544"?> <seriesInfo name="DOI" value="10.17487/RFC8842"/>
<?rfc include="reference.RFC.8122"?>
<?rfc include="reference.I-D.draft-ietf-mmusic-dtls-sdp-24"?> </reference>
<?rfc include="reference.I-D.draft-ietf-tsvwg-sctp-dtls-encaps-09"?>
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-16"?> <!-- draft-ietf-mmusic-sdp-mux-attributes-17 (RFC 8859) -->
<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8
859">
<front>
<title>A Framework for Session Description Protocol (SDP)
Attributes When Multiplexing</title>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8445.xml"/>
<!-- draft-ietf-rtcweb-data-channel: 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='January' year='2021'/>
</front>
<seriesInfo name="RFC" value="8831"/>
<seriesInfo name="DOI" value="10.17487/RFC8831"/>
</reference>
<!-- draft-ietf-mmusic-data-channel-sdpneg: 8864 -->
<reference anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc8864">
<front>
<title>Negotiation Data Channels Using the Session Description
Protocol (SDP)</title>
<author fullname="Keith Drage" initials="K." surname="Drage">
<organization>Unaffiliated</organization>
</author>
<author fullname="Raju Makaraju" initials="M." surname="Makaraju">
<organization>Nokia</organization>
</author>
<author fullname="Richard Ejzak" initials="R." surname="Ejzak">
<organization>Unaffiliated</organization>
</author>
<author fullname="Jerome Marcon" initials="J." surname="Marcon">
<organization>Unaffiliated</organization>
</author>
<author fullname="Roni Even" initials="R." surname="Even" role="editor">
<organization>Huawei</organization>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8864"/>
<seriesInfo name="DOI" value="10.17487/RFC8864"/>
</reference>
<!-- draft-ietf-rtcweb-data-protocol: 8832 -->
<reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832">
<front>
<title>WebRTC Data Channel Establishment Protocol</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='January' year='2021'/>
</front>
<seriesInfo name="RFC" value="8832"/>
<seriesInfo name="DOI" value="10.17487/RFC8832"/>
</reference>
</references>
</references> </references>
<references title="Informative References">
<?rfc include="reference.RFC.5245"?> <section numbered="false" toc="default">
<?rfc include="reference.I-D.draft-ietf-rtcweb-data-channel-13"?> <name>Acknowledgements</name>
<?rfc include="reference.I-D.draft-ietf-mmusic-data-channel-sdpneg-12"?> <t>
<?rfc include="reference.I-D.draft-ietf-rtcweb-data-protocol-09"?> The authors wish to thank <contact fullname="Harald Alvestrand"/>,
</references> <contact fullname="Randell Jesup"/>, <contact fullname="Paul
</back> Kyzivat"/>, <contact fullname="Michael Tüxen"/>, <contact
fullname="Juergen Stoetzer-Bradler"/>, <contact fullname="Flemming
Andreasen"/>, and <contact fullname="Ari Keränen"/> for their
comments and useful feedback. <contact fullname="Ben Campbell"/>
provided comments as part of his Area Director review. <contact
fullname="Brian Carpenter"/> performed the Gen-ART review.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 157 change blocks. 
1225 lines changed or deleted 1341 lines changed or added

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