<?xml version="1.0"?>
<?rfc symrefs="yes"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     docName="draft-ietf-mmusic-sctp-sdp-26" ipr="trust200902">

<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> ipr="trust200902" obsoletes=""
     updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
     symRefs="true" sortRefs="true" version="3" number="8841" consensus="true">

  <!-- xml2rfc v2v3 conversion 2.34.0 -->

  <front>
    <title abbrev="SDP Offer/Answer For for SCTP Over over DTLS">
     Session Description Protocol (SDP) Offer/Answer Procedures
     For
     for Stream Control Transmission Protocol (SCTP) over
     Datagram Transport Layer Security (DTLS) Transport. Transport
    </title>
<seriesInfo name="RFC" value="8841" />
    <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <code>02420</code>
          <city>Jorvas</city>
          <country>Finland</country>
        </postal>
        <email>christer.holmberg@ericsson.com</email>
      </address>
    </author>

    <author fullname="Roman Shpount" initials="R.S." initials="R." surname="Shpount">
      <organization abbrev="TurboBridge">TurboBridge</organization>
      <address>
        <postal>
          <street>4905 Del Ray Avenue, Suite 300</street>
          <city>Bethesda</city>
          <region>MD</region>
          <code>20814</code>
                <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 (240) 292-6632</phone>
        <email>rshpount@turbobridge.com</email>
      </address>
    </author>
    <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
      <organization>Ericsson</organization>
      <address>
        <postal>
                <street>Hirsalantie 11</street>
                <code>02420</code>
                <city>Jorvas</city>
                <country>Finland</country>
          <street>Grönlandsgatan 31</street>
          <city>Kista</city>
          <country>Sweden</country>
        </postal>
        <email>Salvatore.Loreto@ericsson.com</email>
      </address>
    </author>
    <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <code>02420</code>
          <city>Jorvas</city>
          <country>Finland</country>
        </postal>
        <email>Gonzalo.Camarillo@ericsson.com</email>
      </address>
    </author>
    <date year="2017"/>
    <area>RAI</area> year="2021" month="January"/>
    <area>ART</area>
    <workgroup>MMUSIC</workgroup>
    <keyword>SCTP, SDP, DTLS</keyword>
    <keyword>SCTP</keyword>
    <keyword>SDP</keyword>
    <keyword>DTLS</keyword>
    <abstract>
      <t>
            The Stream Control Transmission Protocol (SCTP) is a transport protocol
            used to establish associations between two endpoints.
            draft-ietf-tsvwg-sctp-dtls-encaps-09
            RFC 8261 specifies how SCTP can be used on
            top of the Datagram Transport Layer Security (DTLS) protocol,
	    which is referred to as SCTP-over-DTLS.
      </t>
      <t>
            This specification defines the following new Session Description Protocol (SDP)
            protocol identifiers (proto values):'UDP/DTLS/SCTP' values): "UDP/DTLS/SCTP" and 'TCP/DTLS/SCTP'. "TCP/DTLS/SCTP". This
            specification also specifies how to use the new proto values with the
            SDP Offer/Answer offer/answer mechanism for negotiating SCTP-over-DTLS associations.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
            SDP (Session
        The Session Description Protocol) Protocol (SDP) <xref target="RFC4566"/> target="RFC4566"
	format="default"/> provides a
        general-purpose format for describing multimedia sessions in announcements
        or invitations. TCP-Based "TCP-Based Media Transport in the Session Description Protocol
            (SDP)
        (SDP)" <xref target="RFC4145"/> target="RFC4145" format="default"/> specifies a general
	mechanism for describing and
        establishing TCP <xref target="RFC0793"/> target="RFC0793" format="default"/> streams.
            Connection-Oriented
        "Connection-Oriented Media Transport over the Transport Layer Security (TLS)
        Protocol in SDP the Session Description Protocol (SDP)" <xref target="RFC8122"/>
	target="RFC8122" format="default"/> extends RFC4145
	<xref target="RFC4145"/> for
            describing target="RFC4145" format="default"/> to describe TCP-based media
	streams that are protected using TLS.
      </t>
      <t>
            The Stream Control Transmission Protocol (SCTP) <xref target="RFC4960"/> target="RFC4960" format="default"/> is a
            reliable transport protocol used to transport data between two
            endpoints using SCTP associations.
      </t>
      <t>
      <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/> target="RFC8261" format="default"/> specifies how SCTP can be used on
      top of the Datagram Transport Layer Security (DTLS) protocol, an
      arrangement referred to
      as SCTP-over-DTLS.
      </t>
      <t>
      This specification defines the following new Session Description Protocol (SDP) SDP
      <xref target="RFC4566"/> target="RFC4566" format="default"/> protocol identifiers (proto values):'UDP/DTLS/SCTP'
      values): "UDP/DTLS/SCTP" and 'TCP/DTLS/SCTP'. "TCP/DTLS/SCTP". This specification document also
      specifies how to use the new proto
      values with the SDP Offer/Answer offer/answer mechanism <xref target="RFC3264"/> target="RFC3264"
      format="default"/> for negotiating
      SCTP-over-DTLS associations.
      </t>
<aside>
      <t>
      NOTE: Due to the characteristics of TCP, while multiple SCTP streams can still
      be used, usage of 'TCP/DTLS/SCTP' "TCP/DTLS/SCTP" will always force ordered and reliable delivery
      of the SCTP packets, which limits the usage of the SCTP options. Therefore, it is
      RECOMMENDED
      <bcp14>RECOMMENDED</bcp14> that TCP is only used in situations where UDP traffic is blocked.
      </t>
</aside>
    </section>
    <section title="Conventions"> numbered="true" toc="default">
      <name>Conventions</name>
        <t>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	  "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"></xref>. target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>
    <section title="SCTP Terminology">
      <t>
          SCTP Association: A numbered="true" toc="default">
      <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
          including Verification Tags verification tags and the currently active set of
          Transmission Sequence Numbers (TSNs), etc. An association can be
          uniquely identified by the transport addresses used by the
          endpoints in the association.
      </t>
      <t>
          SCTP Stream: A association.</dd>

          <dt>SCTP stream:</dt>
	  <dd>A unidirectional logical channel established from one to
          another associated
	  SCTP endpoint, endpoint to
          another, within which all user messages
          are delivered in sequence except for those submitted to the
          unordered delivery service.
      </t>
      <t>
          SCTP-over-DTLS: SCTP service.</dd>

          <dt>SCTP-over-DTLS:</dt>
	  <dd>SCTP used on top of DTLS, as specified in
          <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>.
      </t> target="RFC8261" format="default"/>.</dd>
</dl>
    </section>
    <section title="SDP anchor="m-line" numbered="true" toc="default">
      <name>SDP Media Descriptions" anchor="m-line"> Descriptions</name>
      <section title="General" anchor="m-line-gen"> anchor="m-line-gen" numbered="true" toc="default">
        <name>General</name>
        <t>
              This section defines the following new SDP Media Description (m- media description ("m="
              line) protocol identifiers (proto values) for describing an SCTP
              association: 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" and 'TCP/DTLS/SCTP'. "TCP/DTLS/SCTP".  The section also
              describes how an m- line, "m=" line associated with the proto values, values is
              created.
        </t>
        <t>
              The following is the format for an m- "m=" line, as specified in RFC4566
              <xref target="RFC4566"/>: target="RFC4566" format="default"/>:
        </t>
          <figure>
              <artwork><![CDATA[
<sourcecode><![CDATA[
m=<media> <port> <proto> <fmt> ...
              ]]></artwork>
          </figure>
]]></sourcecode>
        <t>
              The 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" and 'TCP/DTLS/SCTP' "TCP/DTLS/SCTP" proto values are similar to both
              the 'UDP' "UDP" and 'TCP' "TCP" proto values in that they only describe the transport-layer
              protocol and not the upper-layer protocol.
        </t>
<aside>
        <t>
              NOTE: When the 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" and 'TCP/DTLS/SCTP' "TCP/DTLS/SCTP" proto values are used,
              the underlying transport protocol is respectively is, respectively, UDP and TCP; SCTP is
              carried on top of DTLS DTLS, which is on top of those transport-layer protocols.
        </t>
</aside>
      </section>
      <section title="Protocol Identifiers" anchor="proto"> anchor="proto" numbered="true" toc="default">
        <name>Protocol Identifiers</name>
        <t>
              The new proto values are defined as below:
        </t>
          <t>
              <list style="symbols">
                  <t>
        <ul spacing="normal">
          <li>
          The 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" proto value describes an SCTP association on top of
          a DTLS association on top of UDP, as defined in
          <xref target="sec-udp-dtls-sctp"/>.
                  </t>
                  <t> target="sec-udp-dtls-sctp" format="default"/>.
                  </li>
          <li>
            The 'TCP/DTLS/SCTP' "TCP/DTLS/SCTP" proto value describes an SCTP association on top of
            a DTLS association on top of TCP, as defined in <xref target="sec-tcp-dtls-sctp"/>.
                  </t>
              </list>
          </t>
	    target="sec-tcp-dtls-sctp" format="default"/>.
                  </li>
        </ul>
      </section>
      <section title="Media Format Management" anchor="media"> anchor="media" numbered="true" toc="default">
        <name>Media-Format Management</name>
        <t>
              <xref target="RFC4566"/> defines target="RFC4566" format="default"/> states that
	      specifications defining new proto values must
              define the rules by which their media format (fmt) namespace is managed.
        </t>
        <t>
              An m- "m=" line with a proto value of 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" or 'TCP/DTLS/SCTP' "TCP/DTLS/SCTP"
              always describes a single SCTP association.
        </t>
        <t>
              In addition, such m- an "m=" line MUST <bcp14>MUST</bcp14> further indicate
	      the application-layer protocol
              using an 'fmt' "fmt" identifier. There MUST <bcp14>MUST</bcp14> be exactly
	      one fmt value per m- "m=" line associated
              with the proto values defined in this specification. The 'fmt' "fmt"
	      namespace associated
              with those proto values describes the generic application usage
	      of the entire SCTP
              association, including the associated SCTP streams.
        </t>

        <t>
              When the 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" and 'TCP/DTLS/SCTP' "TCP/DTLS/SCTP" proto values, values are
              used, the m- "m=" line fmt value,
              identifying which identifies the
              application-layer protocol, MUST <bcp14>MUST</bcp14> be registered by
              IANA.  <xref format="default" pageno="false" target="iana-assusage-registry"/>
              defines the IANA registry for the media format media-format namespace.
        </t>
<aside>
        <t>
              NOTE: A mechanism on for how to describe, describe and manage, manage individual
	      SCTP streams within an
              SCTP association, association is outside the scope of this
	      specification. <xref format="default"
              pageno="false" target="I-D.ietf-mmusic-data-channel-sdpneg"/>
	      target="RFC8864"/> defines
              a mechanism for negotiating individual SCTP streams used to realize WebRTC
              data channels <xref format="default" pageno="false" target="I-D.ietf-rtcweb-data-channel"/>. target="RFC8831"/>.
        </t>
</aside>
      </section>
      <section title="Syntax" anchor="m-line-syn"> anchor="m-line-syn" numbered="true" toc="default">
        <name>Syntax</name>
        <section title="General"> numbered="true" toc="default">
          <name>General</name>
          <t>
                  This section defines the values that can be used within an
                  SDP media description ("m=" line) associated with an
                  SCTP-over-DTLS association.
          </t>
          <t>
                  This specification creates an IANA registry for 'association-usage' "association-usage" values.
          </t>
        </section>
        <section title="SDP numbered="true" toc="default">
          <name>SDP Media Description values">
              <figure>
                  <artwork><![CDATA[

    m= line parameter Values</name>
<t>
When the SCTP association is used to realize a WebRTC data channel
<xref target="RFC8832"/>, the &lt;fmt&gt; parameter value(s)
    ------------------------------------------------------------------
    <media>:                 'application'
    <proto>:                 'UDP/DTLS/SCTP' value is 'webrtc-datachannel'.
</t>

<table anchor="media-desc">
  <name>SDP Media Description Values</name>
  <thead>
    <tr>
      <th>"m=" line parameter</th>
      <th>parameter value(s)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>&lt;media&gt;</td>
      <td>"application"</td>
    </tr>

    <tr>
      <td>&lt;proto&gt;</td>
      <td>"UDP/DTLS/SCTP" or 'TCP/DTLS/SCTP'
    <port>:                  UDP "TCP/DTLS/SCTP"</td>
    </tr>

    <tr>
      <td>&lt;port&gt;</td>
      <td>UDP port number (for 'UDP/DTLS/SCTP')
                             TCP "UDP/DTLS/SCTP")<br/>TCP port number (for 'TCP/DTLS/SCTP')
    <fmt>:                   a "TCP/DTLS/SCTP")</td>
    </tr>

    <tr>
      <td>&lt;fmt&gt;</td>
      <td>A string denoting the association-usage, limited to the syntax of a 'token'
      "token" as defined in RFC4566.

                  ]]></artwork>
              </figure> RFC 4566</td>
    </tr>

  </tbody>
</table>
        </section>
      </section>

      <section title="Example">
          <figure>
              <artwork><![CDATA[ numbered="true" toc="default">
        <name>Example</name>

<sourcecode type="sdp">
 m=application 12345 UDP/DTLS/SCTP webrtc-datachannel
 a=sctp-port:5000
 a=max-message-size:100000

              ]]></artwork>
          </figure>
 a=max-message-size:100000</sourcecode>

<aside>
        <t>
          NOTE: 'webrtc-datachannel' "webrtc-datachannel" indicates the WebRTC Data Channel
          Establishment Protocol defined in <xref target="I-D.ietf-rtcweb-data-protocol"/>. target="RFC8832"
          format="default"/>.
        </t>
</aside>
      </section>
    </section>
    <section title="SDP 'sctp-port' Attribute" anchor="attr-sctp-port"> anchor="attr-sctp-port" numbered="true" toc="default">
      <name>SDP "sctp-port" Attribute</name>
      <section title="General" anchor="attr-sctp-port-gen"> anchor="attr-sctp-port-gen" numbered="true" toc="default">
        <name>General</name>
        <t>
              This section defines a new SDP media-level attribute, 'sctp-port'.
              "sctp-port".  The attribute can be associated with an SDP media
              description (m- ("m=" line) with a 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" or a 'TCP/DTLS/SCTP'
              "TCP/DTLS/SCTP" proto value. In that case case, the m- "m=" line port
              value indicates the port of the underlying transport layer transport-layer
              protocol (UDP or TCP), and the 'sctp-port' "sctp-port" value indicates the
              SCTP port.
        </t>
        <t>
              No default value is defined for the SDP sctp-port "sctp-port"
              attribute. Therefore, if the attribute is not present, the
              associated m- "m=" line MUST <bcp14>MUST</bcp14> be considered invalid.
        </t>
<aside>
        <t>
          NOTE: This specification only defines the usage of the SDP 'sctp-port'
          "sctp-port" attribute when associated with an m- "m=" line containing
          one of the following proto values: 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" or 'TCP/DTLS/SCTP'.
          "TCP/DTLS/SCTP". Usage of the attribute with other proto values
          needs to be defined in a separate specification.
        </t>
</aside>
      </section>
      <section title="Syntax" anchor="attr-sctp-port-syn">
          <t>
              [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
              of this document.]
          </t> anchor="attr-sctp-port-syn" numbered="true" toc="default">
        <name>Syntax</name>
        <t>
              The definition of the SDP 'sctp-port' "sctp-port" attribute is:
        </t>
          <figure>
              <artwork><![CDATA[

   Attribute name:     sctp-port
   Type of attribute:  media
   Mux category:       CAUTION
   Subject to charset: No
   Purpose:            Indicate

	<dl>
	  <dt>Attribute name:</dt>
	  <dd>sctp-port</dd>

	  <dt>Type of attribute:</dt>
	  <dd>media</dd>

	  <dt>Mux category:</dt>
	  <dd>CAUTION</dd>

	  <dt>Subject to charset:</dt>
	  <dd>No</dd>

	  <dt>Purpose:</dt>
	  <dd>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: media
	  description.</dd>

	  <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 1*5(DIGIT) ; DIGIT defined in RFC4566>

   The RFC 4566
	    </sourcecode>
	  </dd>
	</dl>

<t>The SCTP port range is between 0 and 65535 (both included).
   Leading zeroes MUST NOT <bcp14>MUST NOT</bcp14> be used.

   Example: used.</t>

   <t>Example:</t>
<sourcecode type="sdp">
   a=sctp-port:5000

              ]]></artwork>
          </figure>
</sourcecode>

      </section>
      <section title="Mux Category" anchor="attr-sctp-port-mux"> anchor="attr-sctp-port-mux" numbered="true" toc="default">
        <name>Mux Category</name>
        <t>
              The mux category <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> target="RFC8859" format="default"/> for
              the SDP 'sctp-port' "sctp-port" attribute is CAUTION.
        </t>
        <t>
              As the usage of multiple SCTP associations on top of a single
              DTLS association is outside the scope of this specification,
              no mux rules are specified for the 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" and
              'TCP/DTLS/SCTP'
              "TCP/DTLS/SCTP" proto values. Future extensions, extensions that define
              how to negotiate multiplexing of multiple SCTP associations of top of
              a single DTLS association, association need to also define the mux rules for the
              attribute.
        </t>
      </section>
    </section>
    <section title="SDP 'max-message-size' Attribute" anchor="attr-max-message-size"> anchor="attr-max-message-size" numbered="true" toc="default">
      <name>SDP "max-message-size" Attribute</name>
      <section title="General" anchor="attr-max-message-size-gen"> anchor="attr-max-message-size-gen" numbered="true" toc="default">
        <name>General</name>
        <t>
              This section defines a new SDP media-level attribute, 'max-message-size'. "max-message-size".
              The attribute can be associated with an m- "m=" line to indicate the maximum
              SCTP user message size (indicated in bytes) that an SCTP endpoint is willing to
              receive on the SCTP association associated with the m- "m=" line. Different
              attribute values can be used in each direction.
        </t>
        <t>
              An SCTP endpoint MUST NOT <bcp14>MUST NOT</bcp14> send a SCTP user message with a message size
              that is larger than the maximum size indicated by the peer, as it
              cannot be assumed that the peer would accept such a message.
        </t>
        <t>
              If the SDP 'max-message-size' "max-message-size" attribute contains a maximum message size
              value of zero, it indicates that the SCTP endpoint will handle
	      messages of any size,
              subject to memory capacity capacity, etc.
        </t>
        <t>
              If the SDP 'max-message-size' "max-message-size" attribute is not present, the default value is 64K.
        </t>
<aside>
        <t>
              NOTE: This specification only defines the usage of the SDP 'max-message-size' "max-message-size"
              attribute when associated with an m- "m=" line containing one of the following proto
              values: 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" or 'TCP/DTLS/SCTP'. "TCP/DTLS/SCTP".
              Usage of the attribute with other proto values needs to be defined
              in a separate specification.
        </t>
</aside>
      </section>
      <section title="Syntax" anchor="attr-max-message-size-syn">
          <t>
              [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
              of this document.]
          </t> anchor="attr-max-message-size-syn" numbered="true" toc="default">
        <name>Syntax</name>
        <t>
              The definition of the SDP 'max-message-size' "max-message-size" attribute is:
        </t>
          <figure>
              <artwork><![CDATA[

          Attribute name:     max-message-size
          Type of attribute:  media
          Mux category:       CAUTION
          Subject to charset: No
          Purpose:            Indicate

<dl>
      <dt>Attribute name:</dt>
      <dd>max-message-size</dd>

      <dt>Type of attribute:</dt>
      <dd>media</dd>

      <dt>Mux category:</dt>
      <dd>CAUTION</dd>

      <dt>Subject to charset:</dt>
      <dd>No</dd>

      <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.
          Appropriate values: Integer
          Contact name:       Christer Holmberg
          Contact e-mail:     christer.holmberg@ericsson.com
          Reference:          RFCXXXX

          Syntax: media description.</dd>

      <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 1*DIGIT ; DIGIT defined in RFC4566>

          Leading RFC 4566
	</sourcecode>
</dd>

  </dl>

<t>Leading zeroes MUST NOT <bcp14>MUST NOT</bcp14> be used.

          Example: used.</t>
<t>Example:</t>
<sourcecode type="sdp">
   a=max-message-size:100000

              ]]></artwork>
          </figure>
</sourcecode>

      </section>
      <section title="Mux Category" anchor="attr-max-message-size-mux"> anchor="attr-max-message-size-mux" numbered="true" toc="default">
        <name>Mux Category</name>
        <t>
              The mux category for the SDP 'max-message-size' "max-message-size" attribute
              is CAUTION.
        </t>
        <t>
              As the usage of multiple SCTP associations on top of a single
              DTLS association is outside the scope of this specification,
              no mux rules are specified for the 'UDP/DTLS/SCTP' "UDP/DTLS/SCTP" and
              'TCP/DTLS/SCTP'
              "TCP/DTLS/SCTP" proto values.
        </t>
      </section>
    </section>
    <section title="UDP/DTLS/SCTP anchor="sec-udp-dtls-sctp" numbered="true" toc="default">
      <name>UDP/DTLS/SCTP Transport Realization" anchor="sec-udp-dtls-sctp"> Realization</name>
      <t>
          The UDP/DTLS/SCTP transport is realized as described below:
      </t>
      <t>
          <list style="symbols">
              <t>
      <ul spacing="normal">
        <li>
                  SCTP on top of DTLS is realized according to the procedures
                  defined in <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>; target="RFC8261" format="default"/>; and
              </t>
              <t>
              </li>
        <li>
                  DTLS on top of UDP is realized according to the procedures in
                  defined in <xref target="RFC6347"/>.
              </t>
          </list>
      </t> target="RFC6347" format="default"/>.
              </li>
      </ul>
<aside>
      <t>
          NOTE: While <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/> target="RFC8261" format="default"/> allows
          multiple SCTP associations on top of a single DTLS association,
          the procedures in this specification only support the negotiation of a single
          SCTP association on top of any given DTLS association.
      </t>
</aside>
    </section>
    <section title="TCP/DTLS/SCTP anchor="sec-tcp-dtls-sctp" numbered="true" toc="default">
      <name>TCP/DTLS/SCTP Transport Realization" anchor="sec-tcp-dtls-sctp"> Realization</name>
      <t>
          The TCP/DTLS/SCTP transport is realized as described below:
      </t>
      <t>
          <list style="symbols">
              <t>
      <ul spacing="normal">
        <li>
                  SCTP on top of DTLS is realized according to the procedures
                  defined in <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>; target="RFC8261" format="default"/>; and
              </t>
              <t>
              </li>
        <li>
          DTLS on top of TCP is realized using the framing method defined in
          <xref target="RFC4571"/>, target="RFC4571" format="default"/>, with DTLS packets being
	  sent and received
          instead of RTP/RTCP packets using the shim defined in <xref target="RFC4571"/>,
                  so that
	  target="RFC4571" format="default"/>. The length field defined in
	  <xref target="RFC4571"/> target="RFC4571" format="default"/> precedes each DTLS
	  message, and SDP signaling is done according to the procedures
          defined in this specification.
              </t>
          </list>
      </t>
              </li>
      </ul>
<aside>
      <t>
          NOTE: TLS on top of TCP, without using the framing method defined in
          <xref target="RFC4571"/> target="RFC4571" format="default"/>, is outside the scope of this specification.
          A separate proto value would need to be registered for such transport realization.
      </t>
</aside>
    </section>
    <section title="Association And anchor="sec-con-mgmt" numbered="true" toc="default">
      <name>Association and Connection Management" anchor="sec-con-mgmt"> Management</name>
      <section title="General" anchor="sec-con-mgmt-gen"> anchor="sec-con-mgmt-gen" numbered="true" toc="default">
        <name>General</name>
        <t>
              This section describes how to manage an SCTP association, DTLS association association,
              and TCP connection using SDP attributes.
        </t>
        <t>
          The SCTP association, the DTLS association association, and the TCP
	  connection are managed independently
          from each other. Each can be established and closed without impacting others.
        </t>
        <t>
              The detailed SDP Offer/Answer offer/answer <xref target="RFC3264"/> target="RFC3264"
	      format="default"/> procedures for the SDP attributes
              are described in <xref target="sec-sdp-oa"/>. target="sec-sdp-oa" format="default"/>.
        </t>
      </section>
      <section title="SDP sendrecv/sendonly/recvonly/inactive Attribute" anchor="sec-con-mgmt-direction"> anchor="sec-con-mgmt-direction" numbered="true" toc="default">
        <name>SDP "sendrecv"/"sendonly"/"recvonly"/"inactive" Attributes</name>
        <t>
          This specification does not define semantics for the SDP direction
          attributes <xref target="RFC4566"/>. target="RFC4566" format="default"/>. Unless the semantics of these
          attributes for an SCTP association usage have been defined, SDP direction
          attributes MUST <bcp14>MUST</bcp14> be ignored if present.
        </t>
      </section>
      <section title="SCTP Association" anchor="sec-con-mgmt-sctp"> anchor="sec-con-mgmt-sctp" numbered="true" toc="default">
        <name>SCTP Association</name>
        <t>
              When an SCTP association is established, both SCTP endpoints
              MUST
              <bcp14>MUST</bcp14> initiate the SCTP association (i.e. (i.e., both
	      SCTP endpoints take the 'active'
              role), and MUST "active"
              role). In addition, both endpoints <bcp14>MUST</bcp14> use the
	      same SCTP port as client
	      port and server port (in port, in order to
              prevent two separate SCTP associations from being established). established.
        </t>
        <t>
          As both SCTP endpoints take the 'active' "active" role, the SDP 'setup' "setup"
          attribute <xref target="RFC4145"/> target="RFC4145" format="default"/> does not apply to SCTP association
          establishment. However However, the 'setup' "setup" attribute does apply to establishment
          of the underlying DTLS association and TCP connection.
        </t>
<aside>
        <t>
          NOTE: The procedure above is different from TCP, where one endpoint takes the 'active' "active"
          role, the other endpoint takes the 'passive' "passive" role, and only the 'active'
	  "active" endpoint initiates
          the TCP connection <xref target="RFC4145"/>. target="RFC4145" format="default"/>.
        </t>
</aside>
<aside>
        <t>
          NOTE: When the SCTP association is established established, it is assumed that any NAT traversal
          procedures for the underlying transport protocol (UDP or TCP) have successfully been
          performed.
        </t>
</aside>
        <t>
          The SDP 'connection' "connection" attribute <xref target="RFC4145"/> target="RFC4145"
	  format="default"/> does not apply to the SCTP
          association. In order to trigger the closure of an existing SCTP association, association and
          establishment of a new SCTP association, the SDP 'sctp-port' "sctp-port"
	  attribute [<xref target="attr-sctp-port"/>] (<xref target="attr-sctp-port" format="default"/>)
          is used to indicate a new (different than the ones currently used)
	  SCTP port. The existing
          SCTP association is closed, and the new SCTP association is
	  established, if one or both
          endpoints signal a new SCTP port. The 'connection' "connection" attribute does
	  apply to establishment
          of underlying TCP connections.
        </t>

        <t>
          Alternatively, an SCTP association can be closed using the SDP 'sctp-port'
          "sctp-port" attribute with a zero an attribute value. value of zero. Later, a new SCTP
          association can be established using the procedures in this section
          for establishing an SCTP association.
        </t>
        <t>
              SCTP associations might be closed without SDP signalling, e.g, signaling -- for example,
	      in case of a failure.
              The procedures in this section MUST <bcp14>MUST</bcp14> be followed
	      to establish a new
              SCTP association. This requires a new SDP Offer/Answer offer/answer exchange.
              New (different than the ones currently used) SCTP ports MUST
	      <bcp14>MUST</bcp14> be used by both endpoints.
        </t>
<aside>
        <t>
              NOTE: Closing and establishing a new SCTP association using the SDP
              'sctp-port'
              "sctp-port" attribute will not affect the state of the underlying
              DTLS association.
        </t>
</aside>
      </section>
      <section title="DTLS anchor="sec-con-mgmt-dtls" numbered="true" toc="default">
        <name>DTLS Association (UDP/DTLS/SCTP And TCP/DTLS/SCTP)" anchor="sec-con-mgmt-dtls"> and TCP/DTLS/SCTP)</name>
        <t>
        A DTLS association is managed according to the procedures in <xref target="I-D.ietf-mmusic-dtls-sdp"/>.
	target="RFC8842" format="default"/>.
        Hence, the SDP 'setup' "setup" attribute is used to negotiate the (D)TLS roles ('client'
	("client" and 'server') "server")
        <xref target="RFC8122"/>. target="RFC8122" format="default"/>.
        </t>
<aside>
        <t>
        NOTE: The SDP 'setup' "setup" attribute is used to negotiate both the DTLS roles and the
        TCP roles (<xref target="sec-con-mgmt-tcp"/>). target="sec-con-mgmt-tcp" format="default"/>).
        </t>
</aside>
<aside>
        <t>
          NOTE: As described in <xref target="RFC5245"/>, target="RFC8445" format="default"/>, if
	  the Interactive Connectivity
          Establishment (ICE) mechanism <xref target="RFC5245"/> target="RFC8445"
	  format="default"/> is used, all ICE
          candidates associated with a DTLS association are considered part of
	  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 title="TCP anchor="sec-con-mgmt-tcp" numbered="true" toc="default">
        <name>TCP Connection (TCP/DTLS/SCTP)" anchor="sec-con-mgmt-tcp"> (TCP/DTLS/SCTP)</name>
        <t>
        The TCP connection is managed according to the procedures in <xref target="RFC4145"/>.
	target="RFC4145" format="default"/>. Hence,
        the SDP 'setup' "setup" attribute is used to negotiate the TCP roles ('active' ("active"
	and 'passive'), "passive"), and
        the SDP 'connection' "connection" attribute is used to indicate whether to use an
	existing TCP connection, connection
        or create a new one. The SDP 'setup' "setup" attribute 'holdconn' "holdconn" value MUST NOT
	<bcp14>MUST NOT</bcp14> be used.
        </t>
<aside>
        <t>
        NOTE: A change of the TCP roles will also trigger a closure of the
	DTLS association, association and
        establishment of a new DTLS association, according to the procedures
	in <xref target="I-D.ietf-mmusic-dtls-sdp"/>. target="RFC8842" format="default"/>.
        </t>
</aside>
<aside>
        <t>
        NOTE: As specified in <xref target="I-D.ietf-mmusic-dtls-sdp"/>, target="RFC8842" format="default"/>, usage
	of the SDP 'setup' "setup" attribute
        'holdconn'
        "holdconn" value is not allowed. Therefore Therefore, this specification also
	forbids usage of the attribute
        value for TCP, as DTLS is transported on top of TCP.
        </t>
</aside>
      </section>
    </section>
    <section title="SDP anchor="sec-sdp-oa" numbered="true" toc="default">
      <name>SDP Offer/Answer Procedures" anchor="sec-sdp-oa"> Procedures</name>
      <section title="General"> numbered="true" toc="default">
        <name>General</name>
        <t>
        This section defines the SDP Offer/Answer <xref target="RFC3264"/> target="RFC3264" format="default"/>
        procedures for negotiating and establishing an SCTP-over-DTLS association.
        Unless explicitly stated, the procedures apply to both the
        'UDP/DTLS/SCTP'
        "UDP/DTLS/SCTP" and 'TCP/DTLS/SCTP' m- "TCP/DTLS/SCTP" "m=" line proto values.
        </t>
        <t>
        Each endpoint MUST <bcp14>MUST</bcp14> associate one or more certificate fingerprints,
	fingerprints using
        the SDP 'fingerprint' "fingerprint" attribute with the m- "m=" line, following the
	procedures in <xref target="RFC8122"/>. target="RFC8122" format="default"/>.
        </t>
        <t>
        The authentication certificates are interpreted and validated as
        defined in <xref target="RFC8122"/>. target="RFC8122" format="default"/>. Self-signed
        certificates can be used securely, provided that the integrity of the
        SDP description is assured assured, as defined in <xref target="RFC8122"/>. target="RFC8122"
	format="default"/>.
        </t>
        <t>
        Each endpoint MUST <bcp14>MUST</bcp14> associate an SDP 'tls-id' "tls-id" attribute
	with the m- "m=" line,
        following the procedures in <xref target="I-D.ietf-mmusic-dtls-sdp"/>. target="RFC8842" format="default"/>.
        </t>
      </section>
      <section title="Generating anchor="sec-oa-initial-offer" numbered="true" toc="default">
        <name>Generating the Initial SDP Offer" anchor="sec-oa-initial-offer"> Offer</name>
        <t>
         When the offerer creates an initial offer, the offerer:
        </t>
      <t>
      <list style="symbols">
        <t>
          MUST
        <ul spacing="normal">
          <li>
          <bcp14>MUST</bcp14> associate an SDP setup "setup" attribute with the m- "m=" line;
        </t>
        <t>
          MUST
        </li>
          <li>
          <bcp14>MUST</bcp14> associate an SDP 'sctp-port' "sctp-port" attribute with the m- "m=" line;
        </t>
        <t>
          MUST,
        </li>
          <li>
          <bcp14>MUST</bcp14>, in the case of TCP/DTLS/SCTP, associate an SDP 'connection' "connection"
          attribute, with a 'new' "new" attribute value, with the m- "m=" line; and
        </t>
        <t>
          MAY
        </li>
          <li>
          <bcp14>MAY</bcp14> associate an SDP 'max-message-size' "max-message-size" attribute
         [<xref
         (<xref target="attr-max-message-size" />] format="default"/>) with the m- "m=" line.
        </t>
      </list>
      </t>
        </li>
        </ul>
      </section>
      <section title="Generating numbered="true" toc="default">
        <name>Generating the SDP Answer"> Answer</name>
        <t>
          When the answerer receives an offer, which offer that contains an m- "m=" line describing
          an SCTP-over-DTLS association, if the answerer accepts the association,
          the answerer:
        </t>
            <t>
                <list style="symbols">
                    <t>
                        MUST
        <ul spacing="normal">
          <li>
            <bcp14>MUST</bcp14> insert a corresponding m- "m=" line in the
	    answer, with an m- "m=" line
            proto value <xref target="RFC3264"/> target="RFC3264" format="default"/> identical to the value in
            the offer;
                    </t>
                    <t>
                        MUST
                    </li>
          <li>
            <bcp14>MUST</bcp14> associate an SDP 'setup' "setup" attribute with the m- "m=" line;
                    </t>
                    <t>
                        MUST
          </li>
          <li>
            <bcp14>MUST</bcp14> associate an SDP 'sctp-port' "sctp-port" attribute with
	    the m- "m=" line. If the
            offer contained a new (different than the one currently used) SCTP
            port value value, the answerer MUST <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 MUST <bcp14>MUST</bcp14> also associate a zero
            SCTP port value; and
                    </t>
                    <t>
                        MAY
                    </li>
          <li>
            <bcp14>MAY</bcp14> associate an SDP 'max-message-size' "max-message-size" attribute
                        [<xref
            (<xref target="attr-max-message-size" />] format="default"/>) with the m- "m=" line. The
            attribute value in the answer is independent from of the value
            (if present) in the corresponding m- "m=" line of the offer.
                    </t>
                </list>
            </t>
          </li>
        </ul>
        <t>
        Once the answerer has sent the answer the answerer: answer:
        </t>
      <t>
          <list style="symbols">
          <t>
            MUST,
        <ul spacing="normal">
          <li>
            in the case of TCP/DTLS/SCTP, if a TCP connection has not yet
            been established, established or if an existing TCP connection is to be
            closed and replaced by a new TCP connection, one, the answerer
	    <bcp14>MUST</bcp14> follow the procedures
            in <xref target="RFC4145"/> target="RFC4145" format="default"/> for closing and
	    establishing a TCP connection;
          </t>
          <t>
            MUST,
          </li>
          <li>
            if a DTLS association has not yet been established, established or if
            an existing DTLS association is to be closed and replaced by a
            new DTLS association, one, the answerer <bcp14>MUST</bcp14> follow the
	    procedures in <xref target="I-D.ietf-mmusic-dtls-sdp"/> target="RFC8842" format="default"/>
            for closing the currently used, used DTLS association and establishing a new, DTLS association;
	    new one; and
          </t>
          <t>
            MUST,
          </li>
          <li>
            if an SCTP association has not yet been established, established or if an
            existing SCTP association is to be closed and replaced by a new
            SCTP association,
	    one, the answerer <bcp14>MUST</bcp14> initiate the
	    closing of the existing
            SCTP association (if applicable) and establishment of the SCTP new
	    association.
          </t>
        </list>
      </t>
          </li>
        </ul>
        <t>
        If the SDP 'sctp-port' "sctp-port" attribute in the answer contains a zero an attribute
        value,
        value of zero, the answerer MUST NOT <bcp14>MUST NOT</bcp14> establish an SCTP association. If an SCTP
        association exists, the offerer MUST <bcp14>MUST</bcp14> close it.
        </t>
        <t>
        If the answerer does not accept the m- "m=" line in the offer, it MUST <bcp14>MUST</bcp14> assign
        a zero port value to the corresponding m- "m=" line in the answer, following the
        procedures in <xref target="RFC3264"/>. target="RFC3264" format="default"/>. In addition,
	the answerer MUST NOT <bcp14>MUST NOT</bcp14>
        initiate the establishment of a TCP connection, a DTLS association association, or a
        DTLS association associated with the m- "m=" line.
        </t>
      </section>
      <section title="Offerer numbered="true" toc="default">
        <name>Offerer Processing of the SDP Answer"> Answer</name>
        <t>
        Once the offerer has received the answer the offerer: answer:
        </t>
      <t>
        <list style="symbols">
          <t>
            MUST,
        <ul spacing="normal">
          <li>
            in the case of TCP/DTLS/SCTP, if a TCP connection has not yet
            been established, established or if an existing TCP connection is to be
            closed and replaced by a new TCP connection, one, the offerer <bcp14>MUST</bcp14>
	    follow the procedures
            in <xref target="RFC4145"/> target="RFC4145" format="default"/> for closing and
	    establishing a TCP connection;
          </t>
          <t>
            MUST,
          </li>
          <li>
            if a DTLS association has not yet been established, established or if
            an existing DTLS association is to be closed and replaced by a
            new DTLS association, one, the offerer <bcp14>MUST</bcp14> follow the procedures in
	    <xref target="I-D.ietf-mmusic-dtls-sdp"/> target="RFC8842" format="default"/>
            for closing and establishing a DTLS association; and
          </t>
          <t>
            MUST,
          </li>
          <li>
            if an SCTP association has not yet been established, established or if an
            existing SCTP association is to be closed and replaced by a new
            SCTP association,
            one, the offerer <bcp14>MUST</bcp14> initiate the closing of the
	    existing SCTP association (if applicable) and establishment of the SCTP
	    new association.
          </t>
        </list>
      </t>
          </li>
        </ul>
        <t>
        If the SDP 'sctp-port' "sctp-port" attribute in the answer contains a zero an attribute
        value,
        value of zero, the offerer MUST NOT <bcp14>MUST NOT</bcp14> establish an SCTP
	association. If If, in addition, an SCTP
        association exists in that case, exists, the offerer MUST <bcp14>MUST</bcp14> close it.
        </t>
        <t>
        If the m- "m=" line in the answer contains a zero port value, the offerer
        MUST NOT
        <bcp14>MUST NOT</bcp14> initiate the establishment of a TCP
	connection, a DTLS association association,
        or an SCTP association associated with the m- "m=" line. If If, in addition,
	a TCP connection,
        or a
        DTLS association association, or an SCTP association exists in that case, exists, the
	offerer MUST <bcp14>MUST</bcp14> close it.
        </t>
      </section>
      <section title="Modifying numbered="true" toc="default">
        <name>Modifying the Session"> Session</name>
        <t>
        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-initial-offer" />, format="default"/>,
        with the following exceptions:
        </t>
      <t>
      <list style="symbols">
          <t>
        <ul spacing="normal">
          <li>
            If the offerer wants to close an SCTP association, association and immediately
	    establish a new SCTP association,
            the offerer MUST
            it <bcp14>MUST</bcp14> associate an SDP 'sctp-port' "sctp-port"
	    attribute with a new (different than the
            one currently used) attribute value. This will not impact the underlying
            DTLS association (and (or TCP connection connection, in the case of TCP/DTLS/SCTP).
          </t>
          <t>
          </li>
          <li>
            If the offerer wants to close an SCTP association, association without
	    immediately establishing a new
            SCTP association, the offerer MUST it <bcp14>MUST</bcp14> associate an SDP 'sctp-port'
	    "sctp-port" attribute with a zero an attribute
            value.
            value of zero. This will not impact the underlying DTLS association (and (or
	    TCP connection connection, in the case of TCP/DTLS/SCTP).
          </t>
          <t>
          </li>
          <li>
            If the offerer wants to establish an SCTP association, and another
	    SCTP association
            was previously closed, the offerer MUST <bcp14>MUST</bcp14> associate
	    an SDP 'sctp-port' "sctp-port" attribute with
            a new attribute value (different than the value associated with
	    the previous SCTP association).
            If the previous SCTP association was closed successfully following
	    use of an SDP 'sctp-port' "sctp-port" attribute with a zero an
            attribute value, value of zero, the offerer MAY <bcp14>MAY</bcp14> use the same
	    attribute value for the new SCTP association
            that was used with the previous SCTP association before it was
	    closed. This will not impact
            the underlying DTLS association (and (or TCP connection connection, in the case of
	    TCP/DTLS/SCTP).
          </t>
          <t>
          </li>
          <li>
            If the offerer wants to close an existing SCTP association, association and the
            underlying DTLS association (and the underlying TCP connection connection, in
	    the case of
            TCP/DTLS/SCTP) TCP/DTLS/SCTP), it MUST <bcp14>MUST</bcp14> assign a zero port value to
	    the m- "m=" line associated with the
            SCTP and DTLS associations (and TCP connection connection, in the case of TCP/DTLS/SCTP),
            following the procedures in <xref target="RFC3264"/>.
          </t>
          <t> target="RFC3264" format="default"/>.
          </li>
          <li>
            NOTE: This specification does not define a mechanism for explicitly closing a DTLS
            association while maintaining the overlying SCTP association. However, if a DTLS
            association is closed and replaced with a new DTLS association, association as
	    a result of some other action
            <xref target="I-D.ietf-mmusic-dtls-sdp"/>, target="RFC8842" format="default"/>, the state of the SCTP
	    association is not affected.
          </t>
      </list>
      </t>
          </li>
        </ul>

        <t>
        The offer offerer follows the procedures in <xref target="I-D.ietf-mmusic-dtls-sdp"/> target="RFC8842"
        format="default"/> regarding the DTLS association impacts when
        modifying a session.
        </t>
        <t>
        In the case of TCP/DTLS/SCTP, the offerer follows the procedures in
        <xref target="RFC4145"/> target="RFC4145" format="default"/> regarding the TCP connection impacts when
        modifying a session.
        </t>
      </section>
    </section>
    <section title="Multihoming Considerations"> numbered="true" toc="default">
      <name>Multihoming Considerations</name>
      <t>
          Multihoming is not supported when sending SCTP on top of DTLS,
          as DTLS does not expose address management of the underlying
          transport protocols (UDP or TCP) to its upper layer.
      </t>
    </section>
    <section title="NAT Considerations"> numbered="true" toc="default">
      <name>NAT Considerations</name>
      <section title="General"> numbered="true" toc="default">
        <name>General</name>
        <t>
              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).
        </t>
      </section>
      <section title="ICE Considerations"> numbered="true" toc="default">
        <name>ICE Considerations</name>
        <t>
              When SCTP-over-DTLS is used with UDP based UDP-based ICE candidates <xref target="RFC5245"/>
	      target="RFC8445" format="default"/>,
              then the procedures for UDP/DTLS/SCTP [<xref target="sec-udp-dtls-sctp"/>] (<xref
	      target="sec-udp-dtls-sctp" format="default"/>) are used.
        </t>
        <t>
              When SCTP-over-DTLS is used with TCP based TCP-based ICE candidates <xref target="RFC6544"/>
	      target="RFC6544" format="default"/>,
              then the procedures for TCP/DTLS/SCTP [<xref target="sec-tcp-dtls-sctp"/>] (<xref
	      target="sec-tcp-dtls-sctp" format="default"/>) are used.
        </t>
        <t>
              In ICE environments, during the nomination process, endpoints go through multiple
              ICE candidate pairs, pairs until the most preferred candidate pair is found. During
              the nomination process, data can be sent as soon as the first working candidate
              pair is found, but the nomination process still continues continues, and
	      selected candidate pairs
              can still change while data is sent. Furthermore, if endpoints
	      roam between networks, networks -- for instance instance, when a mobile endpoint switches from mobile
	      connection to WiFi, WiFi -- endpoints will
              initiate an ICE restart, which restart. This will trigger a new nomination
	      process between the new set
              of candidates and candidates, which will likely result in the new nominated candidate pair.
        </t>
        <t>
              Implementations MUST <bcp14>MUST</bcp14> treat all ICE candidate pairs associated with
              an SCTP association on top of a DTLS association as part of the same
              DTLS association. Thus, there will only be one SCTP handshake and one DTLS
              handshake even if there are multiple valid candidate pairs, and pairs;
	      shifting from one candidate
              pair to another, including switching between UDP to and TCP
	      candidate pairs, will not impact
              the SCTP or DTLS associations. If new candidates are added, they
	      will also be part of the
              same SCTP and DTLS associations. When transitioning between
	      candidate pairs, different
              candidate pairs can be currently active in different directions directions,
	      and implementations MUST <bcp14>MUST</bcp14>
              be ready to receive data on any of the candidates, even if this
	      means sending and receiving
              data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at the same time in
	      different directions.
        </t>
        <t>
              In order to maximize the likelihood of interoperability between the endpoints, all
              ICE enabled
              ICE-enabled SCTP-over-DTLS endpoints SHOULD <bcp14>SHOULD</bcp14>
	      implement support for UDP/DTLS/SCTP.
        </t>
        <t>
              When an SDP offer or answer is sent with multiple ICE candidates
	      during initial connection
              negotiation or after ICE restart, UDP based UDP-based candidates SHOULD
	      <bcp14>SHOULD</bcp14> be included included, and the default
              candidate SHOULD <bcp14>SHOULD</bcp14> be chosen from one of those UDP
	      candidates. The proto value MUST <bcp14>MUST</bcp14> match
              the transport protocol associated with the default candidate. If UDP transport is used
              for the default candidate, then 'UDP/DTLS/SCTP' the "UDP/DTLS/SCTP" proto value MUST
	      <bcp14>MUST</bcp14> be used. If TCP transport
              is used for the default candidate, then 'TCP/DTLS/SCTP' the "TCP/DTLS/SCTP" proto
	      value MUST <bcp14>MUST</bcp14> be used.
              Note that under normal circumstances circumstances, the proto value for offers
	      and answers sent during ICE
              nomination SHOULD <bcp14>SHOULD</bcp14> be 'UDP/DTLS/SCTP'. "UDP/DTLS/SCTP".
        </t>
        <t>
              When a subsequent SDP offer or answer is sent after ICE
	      nomination is complete, and it does not
              initiate ICE restart, it will contain only the nominated ICE candidate pair.
              In this case, the proto value MUST <bcp14>MUST</bcp14> match the
	      transport protocol associated with the
              nominated ICE candidate pair. If UDP transport is used for the nominated pair,
              then 'UDP/DTLS/SCTP' the "UDP/DTLS/SCTP" proto value MUST <bcp14>MUST</bcp14> be
	      used. If TCP transport is used for the
              nominated pair, then 'TCP/DTLS/SCTP' the "TCP/DTLS/SCTP" proto value MUST
	      <bcp14>MUST</bcp14> be used. Please note that if an endpoint
              switches between TCP-based and UDP-based candidates during the
	      nomination process process, the endpoint
              is not required to send an SDP offer for the sole purpose of
	      keeping the proto value of the
              associated m- "m=" line in sync.
        </t>
<aside>
        <t>
          NOTE: The text in the paragraph above only applies when the usage of ICE
          has been negotiated. If ICE is not used, the proto value MUST
	  <bcp14>MUST</bcp14> always reflect
          the transport protocol used at any given time.
        </t>
</aside>
      </section>
    </section>
    <section title="Examples"> numbered="true" toc="default">
      <name>Examples</name>
      <section title="Establishment numbered="true" toc="default">
        <name>Establishment of UDP/DTLS/SCTP association">
          <figure>
              <artwork><![CDATA[

 SDP Offer: Association</name>

<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

    - The
</sourcecode>
<ul>
    <li>The offerer indicates that the usage of the
      UDP/DTLS/SCTP association will be as defined
      for the 'webrtc-datachannel' "webrtc-datachannel" format value.
    - The value.</li>
    <li>The offerer UDP port value is 54111.
    - The 54111.</li>
    <li>The offerer SCTP port value is 5000.
    - The 5000.</li>
    <li>The offerer indicates that it can take either the
      client or the server DTLS role. role.</li>
</ul>
<t>
SDP Answer: 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

    - The
</sourcecode>

<t>
   Note that due to RFC formatting conventions, this document splits SDP
   across lines whose content would exceed 72 characters. A backslash
   character marks where this line folding has taken place. This backslash and
   its trailing CRLF and whitespace would not appear in actual SDP
   content.</t>

<ul>
    <li>The answerer UDP port value is 64300.
    - The 64300.</li>
    <li>The answerer SCTP port value is 6000.
    - The 6000.</li>
    <li>The answerer takes the server DTLS role.

              ]]></artwork>
          </figure> role.</li>
</ul>

      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
          <xref target="RFC4566"/> target="RFC4566" format="default"/> defines general SDP
	  security considerations, while
          <xref target="RFC3264"/>, target="RFC3264" format="default"/>, <xref target="RFC4145"/> target="RFC4145"
	  format="default"/>, and <xref target="RFC8122"/> target="RFC8122" format="default"/>
          define security considerations when using the SDP offer/answer mechanism
          to negotiate media streams.
      </t>
      <t>
          <xref target="RFC4960"/> target="RFC4960" format="default"/> defines general SCTP security considerations considerations,
          and <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/> target="RFC8261" format="default"/> defines security
          considerations when using SCTP on top of DTLS.
      </t>
      <t>
          This specification does not introduce new security considerations in addition
          to those defined in the specifications listed above.
      </t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section title="New SDP proto values" anchor="iana-sdp-proto" toc="default">
          <t>
              [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.]
          </t> toc="default" numbered="true">
        <name>New SDP Proto Values</name>
        <t>
              This document updates the "Session Description Protocol (SDP)
	      Parameters" registry,
              following the procedures in <xref target="RFC4566" pageno="false" format="default"/>,
              by adding the following values to the table in the SDP "proto" field registry:
        </t>
          <texttable
        <table anchor="table_SDP_proto_values" title='SDP align="center">
          <name>SDP "proto" field values'>
              <ttcol align='center'>Type</ttcol>
              <ttcol align='center'>SDP Name</ttcol>
              <ttcol align='center'>Reference</ttcol>
              <c>proto</c>
              <c>UDP/DTLS/SCTP</c>
              <c>[RFCXXXX]</c>
              <c>proto</c>
              <c>TCP/DTLS/SCTP</c>
              <c>[RFCXXXX]</c>
          </texttable> Field Values</name>
          <thead>
            <tr>
              <th align="center">Type</th>
              <th align="center">SDP Name</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">proto</td>
              <td align="center">UDP/DTLS/SCTP</td>
              <td align="center">RFC 8841</td>
            </tr>
            <tr>
              <td align="center">proto</td>
              <td align="center">TCP/DTLS/SCTP</td>
              <td align="center">RFC 8841</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New SDP Attributes" anchor="iana-sdp-attr" toc="default"> toc="default" numbered="true">
        <name>New SDP Attributes</name>
        <section title="sctp-port" anchor="iana-sdp-attr-sctp-port" toc="default"> toc="default" numbered="true">
          <name>sctp-port</name>
          <t>
                  This document defines a new SDP media-level attribute,'sctp-port'. attribute,"sctp-port". The
                  details of the attribute are defined in <xref
		  target="attr-sctp-port-syn"
                  pageno="false" format="default"/>.
          </t>
        </section>
        <section title="max-message-size" anchor="iana-sdp-attr-max-msg-size" toc="default"> toc="default" numbered="true">
          <name>max-message-size</name>
          <t>
                  This document defines a new SDP media-level attribute,'max-message-size'.
                  attribute,"max-message-size". The details of the attribute
                  are defined in <xref target="attr-max-message-size-syn"
                  pageno="false"
                  format="default"/>.
          </t>
        </section>
      </section>
      <section title="association-usage Name Registry" anchor="iana-assusage-registry" toc="default"> toc="default" numbered="true">
        <name>association-usage Name Registry</name>
        <t>
              [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of
              Per this document.]
          </t>
          <t>
              This specification creates specification, a new IANA registry, registry has been created, following the procedures in
              <xref target="RFC5226"/>, target="RFC8126" format="default"/>, for the namespace associated with the
              'UDP/DTLS/SCTP'
              "UDP/DTLS/SCTP" and 'TCP/DTLS/SCTP' "TCP/DTLS/SCTP" protocol identifiers.
              Each fmt value describes the usage of an entire SCTP association, including
              all SCTP streams associated with the SCTP association.
        </t>
          <t>
              NOTE:

        <aside>
              <t>NOTE: Usage indication of individual SCTP streams is outside the scope of this
              specification.
          </t>
              specification.</t>
        </aside>

        <t>
          The fmt value, "association-usage", value "association-usage" used with these "proto" values is required.
          It is defined in <xref target="m-line"/>. target="m-line" format="default"/>.
        </t>
        <t>
              As part of this registry, IANA maintains the following information:
        </t>
          <t>
              <list style='hanging'>
                  <t hangText="association-usage name:">The

        <dl newline="false" spacing="normal">
          <dt>association-usage name:</dt>
          <dd>The identifier of the subprotocol, as will be used as the fmt value.</t>
                  <t hangText="association-usage reference:">A value.</dd>
          <dt>association-usage reference:</dt>
          <dd>A reference to the document in which the association-usage is defined.</t>
              </list>
          </t>
	  defined.</dd>
        </dl>
        <t>
              association-usage names are to be subject to the "First Come First Served"
              IANA registration policy [RFC5226]. <xref target="RFC8126" format="default" />.
        </t>
        <t>
              IANA is asked to add has added the following initial values to the registry.
        </t>
          <figure anchor="exempleIANA" title="">
              <artwork><![CDATA[

     |----------------------------------------------------------|
     |         name       |           Reference                 |
     |----------------------------------------------------------|
     | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx, |
     |                    | RFCXXX                              |
     |----------------------------------------------------------|

<table anchor="IANA">
  <name>IANA Initial Values</name>
  <thead>
    <tr>
      <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
  until draft-ietf-rtcweb-data-protocol has been published as an RFC.
  Then, replace the reference to draft-ietf-rtcweb-data-protocol
  with the RFC number.]

  [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number
  of this document.]

              ]]></artwork>
          </figure>
</t>
-->
      </section>
    </section>

  </middle>
  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.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/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4145.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4571.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.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/reference.RFC.8261.xml"/>

<!-- draft-ietf-mmusic-dtls-sdp  (RFC 8842) -->
<reference anchor="RFC8842" target="https://www.rfc-editor.org/info/rfc8842">

  <front>
    <title>Session Description Protocol (SDP) Offer/Answer Considerations for
Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)</title>

    <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
      <organization />
    </author>

    <author initials="R." surname="Shpount" fullname="Roman Shpount">
      <organization />
    </author>

    <date month="January" year="2021" />
  </front>
  <seriesInfo name="RFC" value="8842" />
  <seriesInfo name="DOI" value="10.17487/RFC8842"/>

</reference>

<!-- draft-ietf-mmusic-sdp-mux-attributes-17 (RFC 8859) -->
        <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859">
          <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/reference.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>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
          The authors wish to thank Harald Alvestrand, Randell Jesup, Paul Kyzivat,
          Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen and Ari Keranen <contact fullname="Harald Alvestrand"/>,
          <contact fullname="Randell Jesup"/>, <contact fullname="Paul
          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. Ben Campbell <contact fullname="Ben Campbell"/>
          provided comments as part of his AD Area Director review. Brian Carpenter <contact
          fullname="Brian Carpenter"/> performed the Gen-ART review.
      </t>
    </section>

  <section title="">
      <t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
      <t>Changes from draft-ietf-mmusic-sctp-sdp-25
          <list style="symbols">
              <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 management 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 association.</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 section.</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 transports 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>
    <references title="Normative References">
        <?rfc include="reference.RFC.0793"?>
        <?rfc include="reference.RFC.2119"?>
        <?rfc include="reference.RFC.3264"?>
        <?rfc include="reference.RFC.4145"?>
        <?rfc include="reference.RFC.4566"?>
        <?rfc include="reference.RFC.4571"?>
        <?rfc include="reference.RFC.4960"?>
        <?rfc include="reference.RFC.5226"?>
        <?rfc include="reference.RFC.6347"?>
        <?rfc include="reference.RFC.6544"?>
        <?rfc include="reference.RFC.8122"?>
        <?rfc include="reference.I-D.draft-ietf-mmusic-dtls-sdp-24"?>
        <?rfc include="reference.I-D.draft-ietf-tsvwg-sctp-dtls-encaps-09"?>
        <?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-16"?>
    </references>
    <references title="Informative References">
        <?rfc include="reference.RFC.5245"?>
        <?rfc include="reference.I-D.draft-ietf-rtcweb-data-channel-13"?>
        <?rfc include="reference.I-D.draft-ietf-mmusic-data-channel-sdpneg-12"?>
        <?rfc include="reference.I-D.draft-ietf-rtcweb-data-protocol-09"?>
     </references>
  </back>
</rfc>