MMUSIC                                                       C. Holmberg
Internet-Draft                                                 S. Loreto
Internet-Draft                                              G. Camarillo
Intended status: Standards Track                                Ericsson                            G. Camarillo
Expires: January 5, June 1, 2015                                    July 4,                                           Ericsson
                                                       November 28, 2014

Stream Control Transmission Protocol (SCTP)-Based Media Transport in the
                   Session Description Protocol (SDP)
                     draft-ietf-mmusic-sctp-sdp-07
                     draft-ietf-mmusic-sctp-sdp-08

Abstract

   SCTP (Stream Control Transmission Protocol) is a transport protocol
   used to establish associations between two endpoints.

   This document specification describes how to express media transport over describe SCTP in SDP (Session associations using
   the Session Description Protocol).  This document Protocol (SDP), and defines the 'SCTP', 'SCTP/DTLS'
   and 'DTLS/SCTP' following new
   SDP Media Description protocol identifiers for SDP. (proto values):'SCTP',
   'SCTP/DTLS' and 'DTLS/SCTP'.

   The specification also describes how to use the new proto values
   together with the SDP Offer/Answer mechanism in order to negotiate
   and establish SCTP associations, and how to indicate the SCTP
   application usage.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 5, June 1, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Identifier  SCTP Terminology  . . . . . . . . . . . . . . . . . . . . .   3 .   4
   4.  SDP Media Formats Descriptions  . . . . . . . . . . . . . . . . . . .   4
     4.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Media Descriptions
     4.2.  Protocol Identifiers  . . . . . . . . . . . . . . . . . .   5
     4.3.  Media Format Management . . . . . . . . . . . . . . . . .   5
       4.1.1.  sctp-port
     4.4.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.2.  max-message-size
     4.5.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  The Setup and Connection Attributes and Association
       Management  SDP 'sctp-port' Attribute . . . . . . . . . . . . . . . . . .   6
     5.1.  General . . . . . . .   6
   6.  Multihoming . . . . . . . . . . . . . . . . . .   6
     5.2.  Syntax  . . . . . . .   7
   7.  Network Address Translation (NAT) Considerations . . . . . .   8
   8.  Examples . . . . . . . . . . . .   6
   6.  SDP 'fmtp' Attribute  . . . . . . . . . . . . . .   8
     8.1.  Actpass/Passive . . . . . .   7
     6.1.  General . . . . . . . . . . . . . . .   8
     8.2.  Existing Connection Reuse . . . . . . . . . .   7
     6.2.  Syntax  . . . . . .   9
     8.3.  SDP description for SCTP over DTLS Connection . . . . . .   9
     8.4.  SDP description for SCTP over DTLS Connection using
           default values . . . . . . . . . . . . .   7
   7.  SCTP Association Management . . . . . . . .  10
   9.  Security Considerations . . . . . . . . .   7
     7.1.  General . . . . . . . . . .  11
   10. IANA Considerations . . . . . . . . . . . . . . .   7
     7.2.  SDP setup Attribute . . . . . .  11
     10.1.  sctp-port attribute . . . . . . . . . . . . .   7
     7.3.  SDP connection Attribute  . . . . .  12
   11. Acknowledgments . . . . . . . . . . .   8
   8.  SDP Offer/Answer Procedures . . . . . . . . . . . .  12
   12. References . . . . .   8
     8.1.  General . . . . . . . . . . . . . . . . . . . .  12
     12.1.  Normative References . . . . .   8
     8.2.  Generating the Initial SDP Offer  . . . . . . . . . . . .   9
     8.3.  Generating the SDP Answer .  12
     12.2.  Informative References . . . . . . . . . . . . . . .   9
     8.4.  Offerer Processing of the SDP Answer  . .  13
   Authors' Addresses . . . . . . . .  10
     8.5.  Modifying the Session . . . . . . . . . . . . . . .  13

1.  Introduction

   SDP (Session Description Protocol) [RFC4566] . . .  10
   9.  Multihoming Considerations  . . . . . . . . . . . . . . . . .  10
   10. NAT Considerations  . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  General  . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.2.  ICE Considerations . . . . . . . . . . . . . . . . . . .  11
   11. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     13.1.  New SDP proto values . . . . . . . . . . . . . . . . . .  12
     13.2.  New SDP Attribute  . . . . . . . . . . . . . . . . . . .  12
     13.3.  association-usage Name Registry  . . . . . . . . . . . .  13
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     15.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   SDP (Session Description Protocol) [RFC4566] provides a general-
   purpose format for describing multimedia sessions in announcements or
   invitations.  TCP-Based Media Transport in the Session Description
   Protocol (SDP) [RFC4145] specifies a general mechanism for describing
   and establishing TCP (Transmission Control Protocol) [RFC5246]
   streams.  Connection-Oriented Media Transport over the Transport
   Layer Security (TLS) Protocol in the Session Description Protocol
   (SDP) [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based
   media streams that are protected using TLS (Transport Layer Security) [RFC5246].

   This document defines three new protocol identifiers: TLS.

   SCTP :  to describe SCTP-based [RFC4960] media streams.

   SCTP/DTLS :  to describe media streams transported using the Datagram
      Transport Layer Security (DTLS) [RFC4347] protocol over SCTP, as
      specified in [RFC6083].  DTLS over SCTP provides communications
      privacy for applications that use SCTP as their (Stream Control Transmission Protocol) is a transport
      protocol.

   DTLS/SCTP : protocol
   used to establish associations between two endpoints.

   This specification describes how to describe media streams transported using SCTP on top
      of associations using
   the Datagram Transport Layer Security (DTLS) protocol, as
      defined in [I-D.ietf-tsvwg-sctp-dtls-encaps].

   The authentication certificates are interpreted Session Description Protocol (SDP) [RFC4566], and validated as
   defined in RFC4572 [RFC4572].  Self-signed certificates can be used
   securely, provided that defines the integrity of
   following new SDP Media Description [RFC4566] protocol identifiers
   (proto values):'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'.

   The specification also describes how to use the new proto values
   together with the SDP description is
   assured as defined Offer/Answer mechanism [RFC3264] in RFC4572 [RFC4572]. order to
   negotiate and establish SCTP associations, and how to indicate the
   SCTP application usage.

   NOTE: TLS is designed to run on top of a byte-stream oriented
   transport protocol providing a reliable, in-sequence delivery like
   TCP.  Since
   no-one so far has implemented  [RFC6083] presents serious limitations with transporting SCTP
   on top of TLS.  Therefore, defining a mechanism to negotiate media
   streams transported using SCTP on top of TLS is outside the scope of
   this specification.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
   levels for compliant implementations.

3.  SCTP Terminology

   SCTP Association: A protocol relationship between SCTP endpoints,
   composed of the two SCTP endpoints and protocol state information
   including 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.  Two SCTP endpoints MUST NOT have more than one
   SCTP association between them at any given time.

   SCTP Stream: A unidirectional logical channel established from one to
   another associated SCTP endpoint, within which all user messages are
   delivered in sequence except for those submitted to the unordered
   delivery service.

   SCTP Transport address: A transport address is traditionally defined
   by a network-layer address, a transport-layer protocol, and a
   transport-layer port number.  In the case of SCTP running over TLS, due to some serious
   limitations described in [RFC6083], this document does not make use IP, a
   transport address is defined by the combination of TLS over an IP address and
   an SCTP as described in RFC3436 [RFC3436].

   Additionally, this document specifies port number (where SCTP is the use of transport protocol).

4.  SDP Media Descriptions

4.1.  General

   This section defines the 'setup' and
   'connection' following new SDP attributes to establish SCTP associations.  These
   attributes were defined in RFC4145 [RFC4145] Media Description (m-
   line) protocol identifiers (proto values) for TCP.  This document
   discusses their use describing an SCTP
   association: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'.  The section also
   describes how an m- line, associated with SCTP.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
   levels for compliant implementations.

3.  Protocol Identifier proto values, is
   created.

   The following is the format for an 'm' line, as specified in RFC4566
   [RFC4566]:

       m=<media> <port> <proto> <fmt> ...

   This document defines three new values for the 'proto' field: 'SCTP',
   'SCTP/DTLS' and 'DTLS/SCTP'.

   The 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers proto values are similar to
   both the 'UDP' and 'TCP' protocol identifiers proto values in that they only describe the
   transport protocol and not the upper-layer protocol.

   Media described using an 'm' line containing

   NOTE: When the 'SCTP' 'DTLS/SCTP' proto value is used, the underlying
   transport protocol
   identifier is either UDP or TCP.

   The m- line fmt value, identifying the application-layer protocol,
   MUST be registered by IANA.

4.2.  Protocol Identifiers

   The new proto values are carried using defined as below:

   o  The 'SCTP' proto value describes an SCTP association, as defined
      in [RFC4960].

   o  The 'SCTP/DTLS' protocol identifier indicates that the media
   described will use the proto value describes a Datagram Transport Layer
      Security (DTLS)
   [RFC4347] over [RFC6347] connection on top of an SCTP
      association, as specified defined in [RFC6083].

   o  The 'DTLS/SCTP' protocol identifier indicates that the media
   described will use proto value describes an SCTP association on top of the Datagram Transport Layer
   Security (DTLS) protocol
      of a DTLS connection, as specified defined in
      [I-D.ietf-tsvwg-sctp-dtls-encaps].  The actual layer below DTLS can
   be plain UDP or what ICE agrees on (in

   NOTE: In the case ICE is used to
   negotiate of 'DTLS/SCTP', the actual transport flow).  The lower layer used protocol below
   DTLS is
   identified from the elements present inside the m= line block.

   An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' either UDP or 'DTLS/SCTP' MUST
   further qualify TCP.

   OPEN ISSUE #1: It is FFS whether separate proto values will be used,
   depending on whether the application-layer underlying transport protocol using an fmt
   identifier.

   An 'm' line that specifies 'SCTP/DTLS' or 'DTLS/SCTP' MUST provide a
   certificate fingerprint only if the endpoint supports, and is willing
   to use, a cipher suite with an associated certificate.  An SDP
   attribute (an 'a' line) is used to transport and exchange end point
   certificate.  The authentication certificates are interpreted and
   validated as defined in [RFC4572].

4. UDP (e.g.
   'UDP/DTLS/SCTP') or TCP (e.g.  'TCP/DTLS/SCTP').

4.3.  Media Formats

   The SDP specification, [RFC4566], states Format Management

   [RFC4566] defines that specifications defining new proto values, like the SCTP, SCTP/DTLS and DTLS/SCTP proto values
   defined in this RFC, must
   define the rules by which their media format (fmt) namespace is
   managed.  Use of an existing MIME subtype for the format is
   encouraged.  If no MIME subtype exists, it is
   RECOMMENDED recommended that a
   suitable one is registered through the IETF process [RFC4288] [RFC6838]
   [RFC4289] by production of, or reference to, a standards-track RFC
   that defines the transport protocol for the format.

   An m-line m- line with <proto> a proto value of 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP'
   always describe a single SCTP association.

   An 'm'

   In addition, such m- line that specifies 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP' MUST further qualify indicate the application-layer
   protocol using an 'fmt' identifier.

   The 'fmtp' attribute should  There MUST be used to map from exactly one 'fmt'
   value per m- line associated with the 'association-
   usage' (as used proto values defined in an "m=" line) to this
   specification.  The "fmt" namespace associated with those proto
   values describes the max-message-size parameter
   indicating generic application usage of the maximum message size, in bytes, entire SCTP
   association, including the endpoint is
   willing associated SCTP streams.

   NOTE: A mechanism on how to accept.

   The sctp-port attribute specifies the actual sctp port.

    m=application 12345 DTLS/SCTP webrtc-datachannel
    a=fmtp:webrtc-datachannel max-message-size=100000
    a=sctp-port 4060

4.1.  Media Descriptions

   An 'm' line containing the 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP'
   protocol identifier has describe, and manage, individual SCTP
   streams within an SCTP association, is outside the following syntax: scope of this
   specification.

4.4.  Syntax

       sctp-m-line = %x6d "="
        ("application" space SP sctp-port space SP "SCTP"    space  SP sctp-fmt CRLF) /
        ("application" space SP sctp-port space SP "SCTP/DTLS" space SP sctp-fmt CRLF) /
        ("application" space SP udp-port  space  SP "DTLS/SCTP" space SP sctp-fmt CRLF)

       sctp-port = port

       udp-port = port

       sctp-fmt = association-usage

       association-usage = token

4.5.  Example

    m=application 12345 DTLS/SCTP webrtc-datachannel
    a=fmtp:webrtc-datachannel max-message-size=100000

5.  SDP 'sctp-port' Attribute

5.1.  General

   This section defines a new SDP media-level attribute, 'sctp-port'.
   The attribute can be associated with an SDP media description change slightly depending on the actual
   <proto>.

      If the <proto> sub-field is 'SCTP' or 'SCTP/DTLS', the <port> is descriptor (m-
   line) with a 'DTLS/SCTP' proto value, in which case the SCTP transport m- line port (sctp-port) and follows
   value indicates the same active/
      passive offer/answer model described in Section 4.1 port of [RFC4145]. the underlying transport protocol (UDP or
   TCP).

   If the <proto> sub-field SDP sctp-port attribute is 'DTLS/SCTP', not present, the <port> default value is
   5000.

   Usage of the UDP
      transport SDP sctp-port attribute with other proto values is not
   specified, and MUST be discarded if received.

5.2.  Syntax

       sctp-port-attr  =  "a=sctp-port:" portnumber
       port-number     =  port (udp-port).
       port            =  1*DIGIT

6.  SDP 'fmtp' Attribute

6.1.  General

   The <fmt> sub-field carries the parameter indicating the conventional
   usage of SDP 'fmtp' attribute can be used with an entire sctp association (association-usage).

   association-usage:
      The association-usage token indicates the conventional usage of m- line, associated with
   an
      entire sctp association including its streams (e.g. the pairing of
      certain streams, SCTP association, to indicate the protocol carried over certain streams, etc).

      This parameter maximum message size that an
   SCTP endpoint is a required parameter.  [TBD a value willing to receive, for the
      generic usage as defined in RFC 4960 [RFC4960]].

   Any offered a particular SCTP
   association MAY usage, on that SCTP association.

   The remote peer MUST assume that larger messages will be rejected in the answer, for any
   reason.  If an association offer is rejected, by
   the offerer and
   answerer MUST NOT establish an SCTP association for it.  To reject an endpoint.  SCTP association, the <port> endpoints need to decide on appropriate
   behaviour in case a message that exceeds the answer MUST be set maximum size needs to zero.

4.1.1.  sctp-port

       sctp-port-attr   =  "a=sctp-port=" portnumber
       port-number      =  port

   The sctp-port attribute specifies be
   sent.

   If the actual sctp port.  This SDP 'fmtp' attribute is optional and is only meaningful and required if the contains a maximum message size value of
   zero, it indicates the
   <proto> sub-field is 'DTLS/SCTP'. SCTP endpoint will handle messages of any
   size, subject to memory capacity etc.

   If the SDP 'fmtp' attribute is not present, the default value is 5000.

4.1.2.  max-message-size 64K.

6.2.  Syntax

     sctpmap-attr      =  "a=fmtp:" association-usage [max-message-size]
     max-message-size  =  "max-message-size" EQUALS 1*DIGIT

7.  SCTP Association Management

7.1.  General

   The 'fmtp' management of an SCTP association is identical to the management
   of a TCP connection.  An SCTP endpoints MUST follow the rules in
   Section 6 of [RFC4145] to manage SCTP associations.  Whether to use
   the SCTP ordered or unordered delivery service is up to the
   applications using the SCTP association, and this specification does
   not define a mechanism to indicate the type of delivery service using
   SDP.

7.2.  SDP setup Attribute

   If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', the
   SDP setup attribute may be [RFC4145] is used to map from determine the TLS roles,
   following the proceduresin [RFC4572] (the 'active' endpoint will take
   the 'association-usage'
   (as TLS client role).

   The SDP setup attribute is not used in an "m=" line) to determine which endpoint
   initiates the max-message-size parameter
   indicating SCTP association.  Instead, both endpoints MUST
   initiate the maximum message size, in bytes, SCTP association, and MUST use the endpoint same SCTP port as
   client port and server port (in order to prevent two separate SCTP
   associations from being established).

   However, if the proto field value is
   willing 'DTLS/SCTP', and the transport
   layer protocol is TCP (SCTP is carried on top of TCP), the SDP setup
   attribute is also used to accept. negotiate which endpoint will initiate the
   TCP connection (send TCP SYN), following the procedures in [RFC4145].

7.3.  SDP connection Attribute

   The max-message-size parameter indicates SDP connection attribute is used following the maximum message size, procedures in
   bytes,
   [RFC4145], with the endpoint is willing additional SCTP specific considerations described
   in this section.

   In general, the SDP connection attribute only applies to accept.  The peer should assume
   that larger message an SCTP
   association.  Therefore, if the m- line proto field value is 'DTLS/
   SCTP', a connection attribute 'new' value will not automatically re-
   establish an existing DTLS connection, unless some DTLS properties
   are also changed in a way which require the DTLS connection to be rejected by re-
   established.

   However, if the endpoint, though it m- line proto field value is 'SCTP/DTLS', if the SCTP
   association is up re-established, the DTLS connection also needs to be
   re-established.

   OPEN ISSUE #2: Verify that the endpoint decide above statement regarding 'SCTP/DTLS'
   is correct.

8.  SDP Offer/Answer Procedures

8.1.  General

   This section defines the appropriate behaviour.  A parameter with
   value of '0' will signal a best effort attempt, subject to SDP Offer/Answer [RFC3264] procedures for
   negotiating and establishing an SCTP association.  Unless explicitly
   stated, the
   current endpoint memory capacity, procedures apply to handle messages of any size. all protocol identifier values
   ('SCTP', 'SCTP/DTLS' and 'DTLS/SCTP') defined in this specification.

   If the parameter m- line proto value is not present, the implementation should 'SCTP/DTLS' or 'DTLS/SCTP', each
   endpoint MUST provide a
   default, with a suggested value of 64K.

5.  The Setup and Connection Attributes and Association Management

   The use of certificate fingerprint, using the 'setup' and 'connection' attributes in SDP
   'fingerprint' attribute [RFC4145], if the context of
   an SCTP association endpoint supports, and is identical
   willing to the use of these attributes in
   the context of use, a TCP connection.  That is, SCTP endpoints MUST follow
   the rules in Sections 4 cipher suite with an associated certificate.

   The authentication certificates are interpreted and 5 of RFC 4145 [RFC4145] when it comes to validated as
   defined in [RFC4572].  Self-signed certificates can be used securely,
   provided that the use integrity of the 'setup' and 'connection' attributes SDP description is assured as
   defined in offer/answer
   [RFC3264] exchanges. [RFC4572].

   NOTE: The management of an SCTP association is identical procedures apply to the management
   of a TCP connection.  That is, specific m- line describing an SCTP endpoints MUST follow
   association.  If an offer or answer contains multiple m- line
   describing SCTP associations, the rules
   in Section 6 of RFC 4145 [RFC4145] procedures are applied separately
   to manage SCTP associations.
   Whether each m- line.  The procedures related to use the SCTP ordered or unordered delivery service is up SDP attributes apply to
   attributes associated with the applications using m- line describing the SCTP association.

6.  Multihoming

   An SCTP endpoint, unlike a TCP endpoint, can be multihomed.  An SCTP
   endpoint is considered to be multihomed if it has more than one IP
   address.  A multihomed SCTP endpoint informs a remote SCTP endpoint
   about all its IP addresses using
   association.

   EDITOR'S NOTE: The offer/answer proceudres for the address parameters of max-message-size
   value still need to be added.

8.2.  Generating the INIT
   or Initial SDP Offer

   When the INIT-ACK chunk (depending on whether offerer creates an offer, if the multihomed endpoint m- line proto field value
   is 'SCTP/DTLS' or 'DTLS/SCTP', the one initiating offerer MUST insert an SDP setup
   attribute in the establishment of offer, in order to determine the association).
   Therefore, once TLS roles, and in
   cases where SCTP is transported on TCP, determine which endpoint is
   responsible for establishing the address provided TCP connection [Section 7.2].

   The offerer MAY insert an SDP connection attribute, with a 'new'
   value, in the 'c' offer.

   If the value of the m- line has been used proto field is set to
   establish 'DTLS/SCTP', the SCTP association (i.e., to send
   offerer MAY insert an SDP sctp-port attribute, with a value
   indicating the INIT chunk),
   address management is performed using SCTP.  This means that two local SCTP
   endpoints can use addresses that were not listed port, in the 'c' line but
   that were negotiated using SCTP mechanisms.

   During offer.

8.3.  Generating the lifetime of SDP Answer

   When the answerer receives an offer, which contains an m- line
   describing an SCTP association, it MUST insert a corresponding m-
   line, with an identical m- line proto field value, in the endpoints can add and
   remove new addresses from associated
   answer, following the association at any point [RFC5061]. procedures in [RFC3264].

   If the answerer accepts the offered m- line, it assigns the other m-
   line field values according to Section 4.

   If the offer contains an endpoint removes SDP setup attribute, the IP address listed answerer MUST
   insert a setup attribute in its 'c' line from the
   SCTP association, answer, following the endpoint SHOULD update rules in
   [RFC4572] and [RFC4145] (if applicable).

   If the 'c' value of the m- line (e.g., by
   sending a re-INVITE proto field is set to 'DTLS/SCTP', the
   answerer MAY insert an SDP sctp-port attribute, with a new offer) so that it contains value
   indicating the local SCTP port, in the answer.

   Once the answerer has sent the answer, if the SCTP association
   associated with the m- line has yet not been established, or if an IP
   address that
   existing SCTP association is valid within to be re-established, the answer MUST
   start establishing the SCTP association.

   In some environments, intermediaries performing firewall control use association towards the addresses in offer/answer exchanges to perform media
   authorization.  That is, policy-enforcement network elements do peer.

   If the answerer does not
   let media through unless accept the m- line in the offer, it is sent MUST
   assign a zero value to the address port field of the corresponding m- line in
   the 'c' line. answer.  In such network environments, the SCTP endpoints can only exchange
   media using addition, the IP addresses listed answerer MUST NOT insert an SDP setup
   attribute, or an SDP sctp-port attribute, in their 'c' lines.  In these
   environments, the answer.

8.4.  Offerer Processing of the SDP Answer

   When the offerer receives an endpoint wishing to use a different address needs to
   update its 'c' line (e.g., by sending a re-INVITE answer, if the SCTP association
   associated with a new offer)
   so that it contains the new IP address.

   It m- line has not yet been established, or if an
   existing SCTP association is worth to underline that when using SCTP on top of DTLS, only
   single homed SCTP associations can be used, since DTLS does not
   expose any address management to its upper layer.

7.  Network Address Translation (NAT) Considerations re-established, the offerer MUST
   start establishing the SCTP specific features (not present in UDP/TCP), such as association towards the checksum
   (CRC32c) peer.

   If the m- line port field value calculated on in the whole packet (not just answer is zero, the offerer
   MUST terminate the header)
   or its multihoming capabilities, present new challenges for NAT
   traversal.  [I-D.ietf-behave-sctpnat] describes an SCTP specific
   variant of NAT, which provides similar features of Network Address
   and Port Translation (NAPT).

   Current NATs do not typically support SCTP.  As association (if it exists) associated with
   the m- line.

8.5.  Modifying the Session

   When an offerer sends an alternative updated offer, in order to
   design SCTP specific NATs, Encapsulating modify a
   previously negotiated SCTP into UDP [RFC6951]
   makes association, it possible follows the rules in
   Section 8.2, with the following exceptions:

   If the offerer wants to use re-establish an existing SCTP in networks association
   associated with legacy NAT and
   firewalls not supporting SCTP.

   At the time of writing, m- line, the offerer MUST insert an SDP
   connection attribute, with a 'new' value, in the offer.

   If the work on NAT traversal for SCTP m- line proto field value is still
   work in progress.  Additionally, no extension has been defined to
   integrate ICE (Interactive Connectivity Establishment) [RFC5768] with
   SCTP 'SCTP/DTLS' or 'DTLS/SCTP', and its multihoming capabilities either.  Therefore, this
   specification does
   the offer is not define how intended to establish and maintain SCTP
   associations using ICE.  Should this feature be specified for SCTP in re-establish the future, there will be DTLS connection, the
   offerer MUST NOT insert a need SDP setup attribute with a value that
   changes the previously determined TLS roles in the offer.

   If the offerer wants to specify how disable a previously established SCTP
   association, it MUST set the port value of the m- line associated
   with the SCTP association to use them zero, following the procedures in
   [RFC3264].  The offerer MUST NOT insert an SDP
   environment as well.

8.  Examples

   The following examples show the use of the 'setup' and 'connection' setup attribute, or an
   SDP attributes.  As discussed sctp-port attribute, in Section 5, the use of these
   attributes with offer.

   NOTE: Different SCTP association applications might define protocol
   procedures etc that need to be performed before an SCTP association
   is identical to their use with a
   TCP connection.  For the purpose of brevity, terminated.  Such procedures are outside the main portion scope of the
   session description this
   specification.

9.  Multihoming Considerations

   SCTP supports multihoming.  An SCTP endpoint is omitted in the examples, considered multihomed
   if it has more than one IP address on which only show 'm'
   lines and their attributes (including 'c' lines).

8.1.  Actpass/Passive SCTP can be used.  An offerer at 192.0.2.2 signals
   SCTP endpoint inform the remote peer about its availability for IP addresses using the
   address parameters in the INIT/INIT-ACK chunk.  Therefore, when SDP
   is used to describe an SCTP
   association at SCTP port 54111.  Additionally, this offerer is also
   willing association, while the "c=" line contains
   the address which was used to initiate negotiate the SCTP association:

          m=application 54111 association,
   multihomed SCTP t38
          c=IN IP4 192.0.2.2
          a=setup:actpass
          a=connection:new

                                 Figure 1

   The endpoints might end up using other IP addresses.

   If an endpoint at 192.0.2.1 responds removes the IP address [RFC5061] that it offered in
   the SDP "c=" line associated with the SCTP association, it MUST send
   a new Offer, in which the "c=" line contains an IP address with is
   valid within the following description:

          m=application 54321 SCTP t38
          c=IN IP4 192.0.2.1
          a=setup:passive
          a=connection:new

                                 Figure 2

   This will cause association.

   NOTE: In some network environments, intermediaries performing gate-
   and firewall control use the offerer (at 192.0.2.2) address information in the SDP "c=" and
   "m=" lines to initiate authorize media, and will not pass media sent using
   other addresses.  In such network environment, if an SCTP
   association to port 54321 at 192.0.2.1.

8.2.  Existing Connection Reuse

   Subsequent endpoints
   wants to change the exchange in Section 8.1, another offer/answer
   exchange address information on which media is initiated sent and
   received, it needs to send an updated Offer, in the opposite direction.  The endpoint at
   192.0.2.1, which now acts as the offerer, wishes to continue using SDP "c="
   and "m=" lines contain the existing association:

          m=application 54321 new address information.

   Multihoming is not supported when sending SCTP *
          c=IN IP4 192.0.2.1
          a=setup:passive
          a=connection:existing

                                 Figure 3

   The endpoint at 192.0.2.2 also wishes on top of DTLS, as
   DTLS does not expose address management to use the existing its upper layer.

10.  NAT Considerations

10.1.  General

   SCTP
   association and responds with features not present in UDP or TCP, including the following description:

          m=application 54111 SCTP *
          c=IN IP4 192.0.2.2
          a=setup:active
          a=connection:existing

                                 Figure 4

   The existing SCTP association between 192.0.2.2 checksum
   (CRC32c) value calculated on the whole packet (rather than just the
   header), and 192.0.2.1 will be
   reused.

8.3.  SDP description multihoming, introduce new challenges for NAT traversal.
   [I-D.ietf-behave-sctpnat] defines an SCTP over DTLS Connection

   This example shows the usage specific variant of SCTP over DTLS.

   An offerer at 192.0.2.2 signals the availability NAT,
   which provides similar features of Network Address and Port
   Translation (NAPT).

   Current NATs typically do not support SCTP.  [RFC6951] defines a webrtc-
   DataChannel session over SCTP/DTLS.  The DTLS connection runs
   mechanism for sending SCTP on top of port 54111.  The sctp association runs on port 5000 (i.e. sctp-
   port) over DTLS.  The maximum message size, in bytes, the endpoint is
   willing UDP, which makes it possible to accept is 100000 (i.e. max-message-size).

         m=application 54111 DTLS/SCTP webrtc-datachannel
         a=fmtp:webrtc-datachannel max-message-size=100000
             a=sctp-port 5000
         c=IN IP4 192.0.2.2
         a=setup:actpass
         a=connection:new
         a=fingerprint:SHA-1 \
            4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

                                 Figure 5

   The endpoint at 192.0.2.1 responds
   use SCTP with NATs and firewalls that do not support SCTP.

10.2.  ICE Considerations

   At the following description:

         m=application 62442 DTLS/SCTP webrtc-datachannel
             a=fmtp:webrtc-datachannel max-message-size=100000
             a=sctp-port 5000
         c=IN IP4 192.0.2.1
         a=setup:actpass
         a=connection:new
         a=fingerprint:SHA-1 \
            4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

                                 Figure 6

8.4.  SDP description time of writing this specification, no procedures have been
   defined for SCTP over DTLS Connection using default values

   This example shows ICE ICE (Interactive Connectivity Establishment)
   [RFC5768] together with SCTP.  Such procedures, including the usage of SCTP over DTLS when default values
   associated SDP Offer/Answer procedures, are used.

   An offerer at 192.0.2.2 signals outside the availability scope of this
   specification, and might be defined in a webrtc-
   DataChannel session over SCTP/DTLS.  The future specification.

11.  Examples

   TODO: ADD EXAMPLES HERE

12.  Security Considerations

   [RFC4566] defines general SDP security considerations, while
   [RFC3264], [RFC4145] and [RFC4572] define security considerations
   when using the SDP Offer/Answer mechanism to negotiate media streams.

   [RFC4960] defines general SCTP security considerations.  security
   considerations on SCTP in general, while [RFC6083] defines security
   considerations when using DTLS connection runs on top of port 54111.  As the sctp association runs on the default sct-port
   number 5000 over DTLS ant the maximum message size, SCTP.

   This specification does not introduce new security considerations in bytes, the
   endpoint is willing to accept is equal
   addition to those defined in the default value specifications listed above.

13.  IANA Considerations

13.1.  New SDP proto values

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

   This document updates the parameters may be omitted.

   Note that as "Session Description Protocol (SDP)
   Parameters" registry, following the sctp association is meant to be used procedures in [RFC4566], by
   adding the following values to transport
   webrtc data channel, the association-usage parameter is present with table in the webrtc-datachannel value.

          m=application 54111 SDP "proto" field
   registry:

                     +-------+-----------+-----------+
                     |  Type |  SDP Name | Reference |
                     +-------+-----------+-----------+
                     | proto |    SCTP   | [RFCXXXX] |
                     | proto | SCTP/DTLS | [RFCXXXX] |
                     | proto | DTLS/SCTP webrtc-datachannel
          c=IN IP4 192.0.2.2
          a=setup:actpass
          a=connection:new
          a=fingerprint:SHA-1 \
            4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

                                 Figure 7

   The endpoint at 192.0.2.1 responds with the following description, | [RFCXXXX] |
                     +-------+-----------+-----------+

                     Table 1: SDP "proto" field values

13.2.  New SDP Attribute

   [RFC EDITOR NOTE: Please replace RFCXXXX with default value for the sctp-port and max-message-size parameters:

          m=application 62442 DTLS/SCTP webrtc-datachannel
          c=IN IP4 192.0.2.1
          a=setup:actpass
          a=connection:new
          a=fingerprint:SHA-1 \
            4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

                                 Figure 8

9.  Security Considerations

   See RFC 4566 [RFC4566] for security considerations on the use number of this
   document.]

   This document defines a new SDP
   in general.  See RFC 3264 [RFC3264], RFC 4145 [RFC4145] and RFC 4572
   [RFC4572] for security considerations on establishing media-level attribute,'sctp-port', as
   follows:

       Attribute name:     sctp-port
       Type of attribute:  media streams
   using offer/answer exchanges.  See
       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

13.3.  association-usage Name Registry

   [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC 4960 [RFC4960] for security
   considerations on SCTP in general and [RFC6083] for security
   consideration using DTLS on top number of SCTP. this
   document.]

   This specification does not
   introduce any creates a new security consideration in addition to IANA registry, following the ones
   discussed
   procedures in those specifications.

10.  IANA Considerations

   This document defines three new proto values: [RFC5226], for the "fmt" namespace associated with the
   'SCTP', 'SCTP/DTLS' and
   'DTLS/SCTP'.  Their formats are defined in Section 3.  These proto
   values should be registered by 'DTLS/SCTP' protocol identifiers.  Each "fmt"
   value describes the IANA under "Session Description
   Protocol (SDP) Parameters" under "proto". usage of an entire SCTP association, including
   all SCTP streams associated with the SCTP association.

   NOTE: Usage indication of individual SCTP streams is outside the
   scope of this specification.

   The "fmt" value, "association-usage", used with these "proto" is
   required.  It is defined in section Section 4.1.

   [Note] TBD whether a new registry is necessary 4.

   As part of this registry, IANA maintains the following information:

   association-usage Name:  .The identifier of the subprotocol, as will
      be used in the <sctp-fmtp> subfield.

   association-usage reference:  A reference to register the
   different possible "association-usage" values.

10.1.  sctp-port attribute

   This document defines a new SDP session and media-level attribute:

   sctp-port:  Its format is define in section Section 4.1.This
      attribute should which
      the the association usage is defined.

   association-usage names are to be registered by subject to the "First Come First
   Served" IANA under "Session Description
      Protocol (SDP) Parameters" under "att-field" (both session and
      media level)".

11. registration policy [RFC5226].

   IANA is asked to add initial values to the registry.

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

                                 Figure 1

14.  Acknowledgments

   The authors wish to thank Harald Alvestrand, Randell Jesup, Paul
   Kyzivat, Michael Tuexen for their comments and useful feedback.

12.

15.  References

12.1.

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264, June
              2002.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", RFC 4288, December 2005.

   [RFC4289]  Freed, N. and J. Klensin, "Multipurpose Internet Mail
              Extensions (MIME) Part Four: Registration Procedures", BCP
              13, RFC 4289, December 2005.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572, July 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061, September
              2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13, RFC
              6838, January 2013.

   [I-D.ietf-tsvwg-sctp-dtls-encaps]
              Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
              Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
              dtls-encaps-04
              dtls-encaps-06 (work in progress), May November 2014.

12.2.

15.2.  Informative References

   [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
              Layer Security over Stream Control Transmission Protocol",
              RFC 3436, December 2002.

   [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
              Transport Layer Security (DTLS) for Stream Control
              Transmission Protocol (SCTP)", RFC 6083, January 2011.

   [RFC5768]  Rosenberg, J., "Indicating Support for Interactive
              Connectivity Establishment (ICE) in the Session Initiation
              Protocol (SIP)", RFC 5768, April 2010.

   [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
              Control Transmission Protocol (SCTP) Packets for End-Host
              to End-Host Communication", RFC 6951, May 2013.

   [I-D.ietf-behave-sctpnat]
              Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
              Transmission Protocol (SCTP) Network Address Translation",
              draft-ietf-behave-sctpnat-09 (work in progress), September
              2013.

Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com
   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Salvatore.Loreto@ericsson.com

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com