INTERNET-DRAFT                                   R. Fairlie-Cuninghame
Document: draft-fairlie-mmusic-sdp-sctp-00.txt    Nuera Communications
Expires November 2001                                         May 2001



      Guidelines for specifying SCTP-based media transport using SDP
                  <draft-fairlie-mmusic-sdp-sctp-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at:
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:
   http://www.ietf.org/shadow.html

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes a set of guidelines for using the Session
   Description Protocol (SDP) to specify media transport using the
   Stream Control Transmission Protocol (SCTP).  It defines three new
   SDP transport identifiers: "SCTP", "USCTP" and "RTP/AVP-USCTP" that
   provide reliable, unreliable and RTP-based unreliable media
   transport using SCTP.  The document also provides guidelines for
   establishing and managing the SCTP associations used to provide the
   media transport.












Fairlie-Cuninghame                                                   1
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

Introduction

   The Session Description Protocol [SDP] provides a general-purpose
   format for describing multimedia sessions in announcements or
   invitations.  SDP uses an entirely textual data format (the US-ASCII
   subset of [UTF-8]) to maximize portability among transports.  SDP
   does not define a protocol, but only the syntax to describe a
   multimedia session with sufficient information to discover and
   participate in that session.  Session descriptions may be sent using
   any number of existing application protocols for transport (e.g.,
   SAP, SIP, MGCP, RTSP, email, HTTP, etc.).

   The Stream Control Transmission Protocol [SCTP] is a reliable
   transport protocol operating on top of a connectionless packet
   network such as IP.  It offers reliable, non-duplicated transfer of
   user datagrams along with many additional features such as data
   bundling, fragmentation, fault-tolerance for multi-homed endpoints
   and protection from certain flooding and masquerade attacks.  An
   extension to the base SCTP protocol, known as U-SCTP, provides an
   unreliable transport mechanism over SCTP [USCTP].  An SCTP
   association is established through a four-way handshake between two
   SCTP endpoints; the association provides up to 65536 unidirectional
   transport streams in each direction.

   The base SDP specification only describes transport identifiers for
   UDP ("udp") and RTP over UDP ("RTP/AVP").  This document provides
   guidelines for using the session description protocol to describe
   media sessions using SCTP, U-SCTP or RTP over U-SCTP as the
   transport protocol.  The guidelines in this document apply to
   sessions consisting of unicast media announcements in IP based
   networks.  In addition to providing a mechanism for identifying SCTP
   transport streams, the guidelines also provide a mechanism to
   reliably establish and configure the SCTP associations between two
   applications.

Motivation

   The Stream Control Transmission Protocol provides a number of
   advantages over basic TCP transport.  These advantages (including
   those listed briefly in the introduction) are discussed in detail in
   the SCTP specification [SCTP] and the SCTP applicability statement
   [SCTPAS].  The Unreliable-SCTP extension provides many of the same
   advantages over basic UDP transport.  Media transport, such as that
   described by SDP, has traditionally used connectionless, unreliable
   transport protocols such as UDP; interestingly, U-SCTP separates the
   unreliable and connectionless aspects, that is, U-SCTP provides an
   unreliable but (somewhat) connection-oriented transport mechanism.

   The use of SDP to negotiate media sessions with connection-oriented
   transport protocols such as TCP and TLS is described in [COMEDIA].
   However there are a number of important differences between SCTP and
   the connection-oriented transport protocols referenced in that
   document:

Fairlie-Cuninghame      Expires November 2001                        2
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   - SCTP establishes associations between SCTP endpoints rather than
     between the individual media endpoints described in session
     descriptions.
   - Once an SCTP association has been established, data can be sent or
     received on any SCTP stream without further negotiation.
   - The information required to reliably establish an SCTP association
     is greater than the information required to identify the media
     endpoint.
   - SCTP streams are unidirectional and not bidirectional.
   - As SCTP uses chunk bundling and active path probing, it may be
     highly desirable (although not necessary) to establish only a
     single SCTP association between two endpoints and make use of
     multiple streams within the association.

   For these reasons SCTP requires its own SDP transport identifier
   guidelines (as provided by this document) and replaces the SCTP
   transport identifier formerly defined in earlier revisions of the
   [COMEDIA] draft.

   The typical traffic characteristics of RTP-based media (usually
   consisting of small, delay-sensitive packets) make SCTP transport
   especially attractive when there are multiple streams sharing the
   same SCTP association.  Chunk bundling can be used to substantially
   improve bandwidth efficiency for multiple RTP streams.  On low speed
   links the data fragmentation facility becomes useful in reducing
   arrival jitter in RTP media if the SCTP association is shared with
   data or session control traffic (typically containing larger, more
   variable-sized packets).  As for any traffic type, SCTP can provide
   a degree of fault-tolerance when used with multi-homed endpoints.

   The current "RTP/AVP" profile lacks any mechanism to restrict or
   allow the pre-determination of the source address of RTP packets.
   This poses a number of problems for the security of RTP media and
   firewall traversal.  "RTP/AVP-USCTP" by its inherent nature only
   allows RTP media to be received on established SCTP associations.
   Whilst the transport profile does not impose restrictions on the
   remote SCTP endpoint for any association, the profile does however
   optionally allow the establishment of SCTP associations to be
   externally controlled.  In this manner, it is possible that this
   might be used to provide some level of protection from blind
   masquerade attacks on RTP media and assist in firewall traversal (at
   the expense of dynamic association negotiation).  This is not
   necessarily the best approach but does provide a possible avenue for
   small statically configured networks.

1  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119
   [KEYWORDS].



Fairlie-Cuninghame      Expires November 2001                        3
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

2  Definitions

2.1 Identifying and specifying SCTP endpoints

   An SCTP transport address is defined as an IP address (or hostname)
   and SCTP port.  An SCTP endpoint is defined as a set of SCTP
   transport addresses having the same SCTP port value; furthermore,
   SCTP transport addresses may not be shared between SCTP endpoints.
   A single SCTP transport address therefore uniquely identifies the
   SCTP endpoint to which it belongs.  An SCTP association is defined
   by the two SCTP endpoints present in the association.

   For multi-homed SCTP endpoints, the information required to reliably
   create an association to an endpoint is greater than the information
   required to identify the endpoint.  Specifically, although a single
   SCTP transport address is sufficient to identify any multi-homed
   SCTP endpoint, all transport addresses must be known to reliably
   create an association to it.  This is highlighted by considering the
   situation where a subset of the endpoint's transport addresses are
   unreachable when an association must be established.  Assuming that
   at least one transport address is reachable, then in general, an
   association cannot be reliably established unless all transport
   addresses are known.

   Thus, this document uses the phrase "to identify an SCTP endpoint"
   to mean that only enough information is available to uniquely
   identify the SCTP endpoint but not necessarily to fully define it.
   Hence, the endpoint can be identified, however, it may not be
   possible to reliably create a new association to this endpoint.

   The phrase "to specify an SCTP endpoint" is used to mean that enough
   information is provided to both fully define the SCTP endpoint and
   to reliably create a new association to the endpoint.

3  Using SDP to describe SCTP endpoints and streams

   Each SCTP endpoint has control over the properties and usage of the
   outbound (unidirectional) streams in its associations; likewise, the
   properties of the inbound streams are controlled by the remote SCTP
   endpoint (cf.  [USCTP]).  This is an important point to note as SDP
   session advertisements only describe the way in which media can be
   sent to the issuing application, that is, SDP specifies which
   inbound streams must be used for media transport.  This idea drives
   the underlying paradigm for these guidelines: the remote application
   is responsible for taking whatever actions are required to create or
   configure a media path to the issuing application.  This rule is
   slightly complicated by the fact that the remote application may
   have to wait for the issuing application to INITiate an association
   (similar to other connection-based media transport protocols, as
   discussed in [COMEDIA]).

   SCTP media announcements use two basic pieces of information to
   identify the SCTP stream on which media will be expected: the SCTP

Fairlie-Cuninghame      Expires November 2001                        4
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   endpoint and the stream number.  In SDP, the information required to
   identify these two entities will be conveyed by two new SDP
   attributes: "sctpPort" and "sctpStrm" which qualify the connection
   information ("c=") and media announcement ("m=") SDP components
   respectively.

   Generally, existing SCTP associations SHOULD be used in preference
   to creating new associations.  However this may not be possible if
   the existing association's properties are inconsistent with the SDP
   media announcements and reconfiguration of the association is not
   possible.  When a new association must be established, the set of
   information used/supplied by an application to create/accept an
   association is as follows:
   - A list of remote transport addresses used for creating an
     association.
   - An indication of whether the issuing application will INITiate or
     wait for an association.
   - The number of inbound streams requested by the issuing
     application.
   - The type of the inbound streams (SCTP or U-SCTP).
   - The set of extensions/capabilities implemented by the SCTP stack.
   - Optionally, the first transport address to try when attempting a
     connection.

   This information is conveyed in two new SDP attributes: "sctpAssn"
   and "sctpOptn".

3.1 SCTP connection information ("c=")

   The primary role of the SCTP connection information component is to
   identify (and possibly specify) an SCTP endpoint.  The single IP
   address normally present in a connection information ("c=") line is
   not sufficient to identify an SCTP endpoint.  The "sctpPort"
   attribute is introduced in this document to provide the additional
   SCTP port information required for SCTP endpoint identification.

   SCTP connection information ("c=") components MUST include the
   "sctpPort" attribute ("a=") in the same media or session-level
   section as the connection information ("c=") line.  In other words,
   a connection information ("c=") line refers to an SCTP endpoint if
   the "sctpPort" attribute is present in the same media or session-
   level section.  Additionally, any media announcements ("m=")
   referencing the SCTP connection information ("c=") line MUST be an
   SCTP media announcement (and vice versa).

   The "sctpAssn" attribute further specifies the SCTP endpoint (and
   the desired association) identified by the SCTP connection
   information ("c=").  This attribute may be present in any section
   where the "sctpPort" attribute is present.  The semantics of this
   attribute are defined in Section 4.1.

   If the address specified in the connection information ("c=") line
   is equal to zero and the "sctpPort" attribute is present then it is

Fairlie-Cuninghame      Expires November 2001                        5
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   still treated as a valid SCTP connection information ("c=")
   component but any associated media announcements should be treated
   as "on hold" or inactive.

   The IP address in the connection information ("c=") SHOULD be set
   equal to the primary address of the SCTP endpoint but applications
   MUST be able to identify the SCTP endpoint using any constituent
   SCTP transport address.

3.2 SCTP media announcements ("m=")

   An SCTP media announcement is defined to be any SDP media
   announcement ("m=") where the <transport> identifier is equal to one
   of the identifiers specified in this document.  For SCTP media
   announcements, the SDP protocol-specific <port> value is defined to
   be a 32-bit number that will be referred to as the SCTP media
   "announcement identifier" and is described below.

   Therefore the format of an SCTP media announcement is

   m=<media> <announcement-id> <transport> <fmt list>

   where <transport> is one of the transport identifiers listed in
   Section 3.2.2.  The semantics of the <media>, <transport> and <fmt
   list> values are unchanged from the basic media announcement defined
   in [SDP].  The semantics of the <announcement-id> field is described
   in the section below.

   All SCTP media announcements MUST include the "sctpStrm" attribute
   as a media-level attribute.  This attribute is described in Section
   4.4.

3.2.1     Semantics of the SCTP media announcement identifier

   The value of the <announcement-id> is chosen by the application to
   be a non-zero value (for accepted announcements) that uniquely maps
   to the specified stream for the lifetime of the media session.  This
   preserves the property exhibited by normal UDP or TCP port values
   whereby each media announcement uses a different port value within
   the same connection information ("c=") component.  [An
   <announcement-id> value equal to the stream number plus one would
   suffice as a simple mapping scheme.]

   An <announcement-id> value of zero has special significance in some
   application protocols ([SIP] for instance) and so this value MUST
   not be used in accepted or offered media announcements.

3.2.2     SCTP transport identifiers

   This document introduces three new media transport identifiers:
   "SCTP", "USCTP", and "RTP/AVP-SCTP".  Each is described below:



Fairlie-Cuninghame      Expires November 2001                        6
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

3.2.2.1   "SCTP"

   The "SCTP" transport identifier provides a reliable, ordered or
   unordered datagram service over SCTP as described in the base SCTP
   specification [SCTP].  This transport identifier is analogous to the
   transport service provided by "TCP" transport identifier described
   in [COMEDIA].

   It is up to the sending application to determine whether "SCTP"
   datagrams should be transported in an ordered or unordered manner
   and this may chosen on a per-packet basis as described in [SCTP].

3.2.2.2   "USCTP"

   The "USCTP" transport identifier provides an unreliable, ordered or
   unordered datagram service over U-SCTP.  The U-SCTP extension to
   SCTP is described in [USCTP].  This transport identifier corresponds
   to the "udp" transport service described in [SDP].

   It is up to the sending application to determine whether "USCTP"
   datagrams should be transported in an ordered or unordered manner
   and this may chosen on a per-packet basis as described in [USCTP].

3.2.2.3   "RTP/AVP-USCTP"

   The "RTP/AVP-USCTP" transport identifier provides an unreliable,
   unordered datagram service (using U-SCTP) for RTP media conforming
   to the RTP Profile for Audio and Video Conferences with Minimal
   Control [AVP].  As such, "RTP/AVP-USCTP" corresponds to the
   "RTP/AVP" transport service which uses UDP to provide the unreliable
   datagram transport.

   The RTP profile [AVP] states that definitions in the profile do not
   preclude the use of other lower layer protocols and that RTP uses
   the SSRC field to identify media sources rather than transport
   addresses.  [The selection of the CNAME record in RTCP SDES records
   for multi-homed hosts is beyond the scope of this document.]

   For the "RTP/AVP-USCTP" transport identifier, RTP packets are sent
   on outbound SCTP streams rather than to destination UDP ports, so
   all mention of RTP ports in [RTP] and [AVP] should instead be
   interpreted as referring to an SCTP stream number.

   As such, all RTP datagrams MUST be carried on an even numbered
   stream and all RTCP datagrams are carried on the next (odd-numbered)
   stream.  "RTP/AVP-USCTP" also differs in the range of the valid
   stream numbers - there is no lower limit due to reserved UDP ports,
   that is, any even U-SCTP stream pair in an association may be used
   to carry RTP/RTCP (including the zero stream).

   When sending any RTP packet over U-SCTP the unordered bit MUST be
   set in the data chunk (RTP packets contain their own timestamp).
   The payload identifier of the data chunk MUST be set to 0x000A for

Fairlie-Cuninghame      Expires November 2001                        7
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   all RTP and RTCP packets transmitted under this transport
   identifier.

4  New SDP attribute semantics ("a=")

4.1 Semantics of the "sctpPort" attribute

   The "sctpPort" attribute specifies that the associated connection
   information ("c=") line refers to an SCTP endpoint.  In other words,
   the "sctpPort" attribute can only be present as a session-level
   attribute if a session-level connection information ("c=") line
   exists and can only be present as a media-level attribute if a
   media-level connection information ("c=") line exists.  The
   "sctpPort" attribute specifies the local SCTP port to be used by the
   SCTP endpoint.  An endpoint can thus be identified by the
   combination of the SCTP port and the address information in the
   connection information ("c=") line (or the "sctpAssn" attribute
   described below).

   The format of the "sctpPort" attribute is as follows:

   sctpport-attribute         = "sctpPort:" port-number

   port-number                = 1*DIGIT

4.2 Semantics of the "sctpAssn" attribute

   The "sctpAssn" attribute is an optional but RECOMMENDED attribute
   that allows the SCTP association to be dynamically negotiated.

   The format of the "sctpAssn" attribute is:

   sctpassn-attribute         = "sctpAssn:" transport-address-list
                                   SP number-inbound-streams
                                   SP inbound-usctp-stream-list
                                   SP direction
                                   [ SP initial-transport-address ]

   transport-address-list     = (IPv4address | Ipv6reference)
                                      *("," IPv4address|Ipv6reference)
                                   | hostname

   number-inbound-streams     = 1*DIGIT

   inbound-usctp-stream-list  = ( 1*DIGIT "-" 1*DIGIT)
                                      *("," 1*DIGIT "-" 1*DIGIT) )
                                   | "-" | "x"

   direction                  = "passive" | "active" [":" source-port]
                                   | "both" [":" source-port]

   source-port                = 1*DIGIT


Fairlie-Cuninghame      Expires November 2001                        8
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   initial-transport-address  = (IPv4address | Ipv6reference)

   The sctpassn-attribute MUST NOT contain spaces except where
   explicitly noted above.

   - The transport-address-list specifies a list of IP addresses or a
     single fully qualified DNS hostname that make up the SCTP
     endpoint.  An application may send an INIT to any of these
     addresses to create an association (direction parameter
     permitting).  The list SHOULD include all transport addresses used
     by the endpoint and the primary address SHOULD occur first.  The
     address in the connection information ("c=") line MUST be present
     in the transport-address-list.
   - The number-inbound-streams value specifies the number of inbound
     streams the issuing application desires.  This value is also used
     when generating the INIT or INIT_ACK chunks during association
     negotiation.
   - The inbound-usctp-stream-list specifies which of the inbound
     streams are to be configured as U-SCTP.  If the issuing
     application does not support U-SCTP then it MUST place an "x" in
     this field.  If the issuing application does support U-SCTP but
     does not want to configure any U-SCTP streams then it places a "-"
     in this field.  An example of a valid inbound-usctp-stream-list
     value for a 100 inbound streams is "0-50,75-99".
   - The direction and source-port fields are based on the "direction"
     attribute described in [COMEDIA].  The direction field defined
     here has the same meaning as in [COMEDIA], however, it is only
     relevant in establishing an SCTP association and has no
     significance for each individual media announcement.  The optional
     source-port field specifies the source SCTP port that will be used
     when sending an INIT chunk; this corresponds to the source port
     field described in [COMEDIA].
   - The initial-transport-address indicates the address the remote
     application MAY initially send an INIT chunk to.  An application
     SHOULD generate this value when it knows that the primary
     transport address is unreachable from the remote application.  If
     the transport-address-list field is not a DNS hostname then the
     address in initial-transport-address MUST be one of the addresses
     in this list.  Otherwise, if the transport-address-list field is a
     DNS hostname then the initial-transport-address value MAY still be
     used as the initial destination address; however, if this
     association attempt fails a normal DNS lookup MUST be performed.

   If the "sctpAssn" attribute is omitted in the remote application's
   session advertisement, then the local application must either:
   use static or external configuration information to initiate the
   SCTP association, or rely on the SCTP association being already
   established.

   Applications SHOULD treat as an error the situation where an SCTP
   association cannot be established, for instance, when the "sctpAssn"
   attribute is not present and external configuration or an existing
   association does not exist.  Applications MUST NOT guess endpoint

Fairlie-Cuninghame      Expires November 2001                        9
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   address information from the connection information (c=) line
   address, that is, if the "sctpAssn" attribute is missing and there
   is no external configuration then the application MUST NOT attempt
   to INITiate an association.

   An application MAY ignore the "sctpAssn" attribute in a session
   description if an association to the remote SCTP endpoint
   (identified by the connection information ("c=") address and
   "sctpPort" value) is already established and has the correct inbound
   stream type for all media announcements using the endpoint.

4.3 Semantics of the "sctpOptn" attribute

   The "sctpOptn" attribute lists the SCTP extensions implemented by
   the issuing application's SCTP stack.  The "sctpOptn" attribute is
   an optional attribute that can occur anywhere that the "sctpAssn"
   can occur.  It is not necessary to indicate support of the U-SCTP
   extension in the "sctpOptn" attribute as this can be determined from
   the "sctpAssn" attribute.

   sctpoptn-attribute         = "sctpOptn:" sctp-option
                                   *("," sctp-option)

   sctp-option                = token

4.4 Semantics of the "sctpStrm" attribute

   The "sctpStrm" attribute MUST be present in every SCTP media
   announcement and cannot appear as a session-level attribute.  The
   "sctpStrm" attribute specifies the stream number on which the
   application expects to receive media for the media announcement
   ("m=").

   The format of the "sctpStrm" attribute is

   sctpstrm-attribute         = "sctpStrm:" stream-number
                                   [ "/" number-of-streams ]

   stream-number              = 1*DIGIT

   number-of-streams          = 1*DIGIT

   - The stream-number MUST have a value between 0 and the configured
     number of inbound streams minus one.
   - The number-of-streams value is the number of contiguous streams
     used by this media announcement.

   SCTP media announcements using the "RTP/AVP-USCTP" transport
   identifier must specify an even stream number as described in
   Section 3.2.2.3.

5  Handling of existing SDP parameters


Fairlie-Cuninghame      Expires November 2001                       10
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

5.1 "recvonly" & "sendonly" attributes.

   Many protocols use SDP to form logical bidirectional media paths
   using two session descriptions (one issued by each endpoint).  SDP
   allows an application to configure a media path to be unidirectional
   at the application level by specifying the "sendonly" or "recvonly"
   attributes in at least one session description.

   As the "sendonly" or "recvonly" attributes refer only to the
   application-level media path, valid media announcements are still
   generated in both directions, however, the exact definition of
   "sendonly" and "recvonly" is application specific.  Normally (for
   example in SIP and MGCP), this means that any media payload packets
   received in the unused direction are discarded.  For "RTP/AVP-USCTP"
   streams it should be remembered that RTCP reports MUST still be
   generated and sent in the reverse (unused) direction (as for
   "RTP/AVP").

6  Guidelines for opening SCTP associations

   An application will normally open a new association when a media
   announcement is received identifying an SCTP endpoint for which a
   usable association is not established (or not in the process of
   being established).  In this context a usable association is an
   association with a usable stream that is connected to the remote
   SCTP endpoint specified in the remote session description.  For
   bidirectional media sessions using two complementary session
   descriptions, a usable association is also an association with a
   usable stream that is connected to the local SCTP endpoint of the
   corresponding local session description.

   The direction field in the "sctpAssn" attribute may however force
   the application to wait for the remote application to INITiate the
   association.  If both the local and remote application have
   generated complementary session descriptions, then it is RECOMMENDED
   that the initial association be established between the two
   endpoints described in the session descriptions.  New associations
   SHOULD be established so as to satisfy the requirements of all media
   announcements referencing the local and remote endpoints.

   If an address is present in the initial-transport-address field and
   the session description was issued relatively recently then this
   address SHOULD be used for the initial INIT chunk destination when
   attempting to open an SCTP association; otherwise the primary
   address SHOULD be used initially.  If an association attempt to the
   initial address fails, the application MUST attempt to establish an
   association with the other known transport addresses.  If the
   ASSOCIATE primitive of the SCTP implementation only accepts a single
   destination address then the application MUST provide this fault-
   tolerant behavior.  The application SHOULD configure a small number
   of retransmits for the INIT chunk to ensure that the alternative
   addresses can be tried in a timely manner.


Fairlie-Cuninghame      Expires November 2001                       11
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   If multiple associations are established using this method, then the
   application SHOULD choose only one association and terminate the
   others.  It is up to the application to decide whether or not to
   accept an association where the negotiated remote transport address
   set does not match the address set in the remote session
   description.

   When INITiating an association, the maximum number of outbound
   streams specified in the INIT chunk SHOULD be set to the
   application's implementation or pre-configured maximum value.  If
   the application expects to receive media on the local SCTP endpoint
   then the maximum number of inbound streams specified in the INIT
   chunk SHOULD be set to the number-inbound-streams value specified in
   the "sctpAssn" attribute of the local session description.

   When accepting an association, the maximum number of outbound
   streams specified in the INIT                               .ACK chunk SHOULD be set to the minimum
   of the number of inbound streams specified in the INIT chunk and the
   implementation or pre-configured maximum value.  If the application
   expects to receive media on the local SCTP endpoint then the maximum
   number of inbound streams specified in the INIT                                                 .ACK chunk SHOULD be
   set to the minimum of the number of outbound streams specified in
   the INIT chunk and the number-inbound-streams value specified in the
   "sctpAssn" attribute of the local session description.

   In this way the negotiated number of SCTP streams in each used
   direction is equal to the minimum of the requested value and the
   remote implementation or pre-configured maximum value.  The behavior
   when the remote application indicates a maximum number of outbound
   streams that is smaller than the requested number of inbound streams
   is application specific.

   An application MAY provide hints that an association SHOULD be
   opened/modified without announcing media by presenting a session
   description with a session-level SCTP connection information ("c=")
   line but no media announcements ("m=").

7  Guidelines for modifying or adding SCTP associations

   It is the sender's responsibility to generate an association with
   the appropriate properties to satisfy the remote session
   description.  This may either require that a new association is
   created with the desired stream properties or that an existing
   association is modified to become consistent.  Adding or restarting
   an association may be required when the number of streams or the
   type of streams (reliable or unreliable) in the existing
   associations differs to what is being requested by the media
   announcements in the remote session description.

   Restarting (rather than adding) an association SHOULD be performed
   when an application wishes to maintain a single association with the
   remote application.  However, restarting an association may result
   in a temporary disruption to media flow during the restart.

Fairlie-Cuninghame      Expires November 2001                       12
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001


   If an application chooses to replace the association currently being
   used to send media then the application should open a new
   association in accordance with the guidelines outlined in the
   previous section.  Additionally, the new association SHOULD satisfy
   the requirements of all media announcements using the local and
   remote endpoints.

8  Guidelines for sending and accepting data on SCTP associations

   If only one application has issued a session description then the
   other application is limited to sending media on associations where
   the remote SCTP endpoint matches the endpoint specified in the
   remote media announcement.  However when both applications have
   issued complementary session descriptions (to establish
   bidirectional media sessions) then an application may send media on
   any association where either the local or remote endpoint matches an
   SCTP endpoint identified in the corresponding session description.

   Once an application begins sending media on a particular association
   it SHOULD NOT change to sending on a different association whilst
   the current association remains established.  This ensures that end-
   to-end ordering is maintained and that race conditions for closing
   streams do not occur.  It does however mean that bandwidth
   efficiency (from the chunk bundling of data and SACK's) is reduced
   when associations are not restarted as described in the previous
   section.

   An application SHOULD accept data on any association with the local
   SCTP endpoint as long as the stream type is consistent with the
   relevant media announcement.  For bidirectional media sessions where
   the "sctpAssn" attribute was placed in the local session
   description, the application SHOULD also accept data on any
   association connected to the remote SCTP endpoint in the
   corresponding remote session description.

9  Guidelines for closing an SCTP association

   If an application has multiple associations established for any
   media announcement, the application MAY choose to terminate the
   unused associations to reclaim the resources associated with them.
   However, in this case, the application SHOULD NOT close any
   association where data has been sent or received for an active media
   announcement.

   An application MAY indicate that all associations to a local SCTP
   endpoint are no longer required by presenting a session description
   containing a session-level SCTP connection information ("c=") line
   with a zero address and no media announcements ("m=").  In this case
   the SCTP endpoint is identified using the "sctpAssn" attribute.  How
   these indications are actually used (if at all) will depend on the
   application in which SDP is used - SDP merely provides a means to
   convey this information.

Fairlie-Cuninghame      Expires November 2001                       13
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001


10 New format identifiers for the "SCTP" transport identifier

   The IETF SIGTRAN working group has developed a number of adaptation
   layers for transporting telephony signaling over SCTP.  As SDP can
   also be conveniently used to describe these signaling connections,
   SDP format identifiers will be defined for these SCTP adaptation
   layers.

   SDP format identifiers for the "SCTP" transport identifier:

   "iua" - ISDN Q.921 User Adaptation Layer [IUA]
   "m2ua" - MTP2 User Adaptation Layer [M2UA]
   "m2pa" - MTP2 User Peer-to-peer Adaptation Layer [M2PA]
   "m3ua" -  MTP3 User Adaptation Layer [M3UA]
   "sua" - SS7 SCCP User Adaptation Layer [SUA]
   "v5ua"  - V5.2 User Adaptation Layer [V5UA]

11 SDP Examples

   The following examples demonstrate how the above guidelines may be
   used to describe SCTP media transport.

   For clarity minimal values are used for  "o=", "s=", "t="
   components.  In normal applications the appropriate values should be
   used.

11.1 Minimal SCTP session description (no association information)

   v=0
   o=- 0 0 IN IP4 10.0.0.1
   s=-
   c=IN IP4 10.0.0.1
   t=0 0
   a=sctpPort:5000
   m=audio 1 RTP/AVP-USCTP 0 8
   a=sctpStrm:0
   m=video 2 RTP/AVP-USCTP 31
   a=sctpStrm:2

   This example uses a session level SCTP connection information ("c=")
   component with two SCTP media announcements.  As the "sctpAssn"
   attribute is missing, the applications can only use existing or
   externally configured SCTP associations for media transport.

11.2 Multiple SCTP associations

   v=0
   o=- 0 0 IN IP4 10.0.0.1
   s=-
   t=0 0
   m=control 10 SCTP m2ua
   c=IN IP4 10.0.0.1

Fairlie-Cuninghame      Expires November 2001                       14
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   a=sctpPort:6000
   a=sctpAssn:10.0.0.1,10.0.0.2 10 - both:11000 10.0.0.2
   a=sctpStrm:0
   m=audio 20 RTP/AVP-USCTP 0 8
   c=IN IP4 10.0.0.1
   a=sctpPort:5000
   a=sctpAssn:10.0.0.1,10.0.0.2 100 0-99 both:10000 10.0.0.2
   a=sctpStrm:0

   This example uses two separate SCTP associations.  One association
   is configured to have 10 inbound SCTP streams and the other is
   configured to have 100 inbound U-STCP streams.  Both associations
   will attempt to establish the association but will also accept an
   inbound association.  In both cases the issuing application is
   indicating that the remote application should use 10.0.0.2 as the
   destination for the initial INIT chunk.  The SCTP implementation has
   not indicated that it supports any extensions beside U-SCTP.

11.3 Mixed media announcements

   v=0
   o=- 0 0 IN IP4 bob.company.com
   s=-
   c=IN IP4 bob.company.com
   t=0 0
   m=data 10000 TCP t38
   a=direction:both
   m=audio 1 RTP/AVP-USCTP 0
   c=IN IP4 bob.company.com
   b=AS:64
   a=sctpPort:10001
   a=sctpAssn:bob.company.com 100 50-99 active
   a=sctpOptn:addip,srwnd
   a=sctpStrm:50

   This example uses one TCP and one SCTP media announcement.  The SCTP
   announcement indicates that the issuing application will INITiate an
   association to SCTP endpoint specified in the remote applications
   session description.  The "sctpOptn" attribute values listed in this
   example are as yet undefined.

12 Security Considerations

   See [SDP] for security and other considerations relating to the
   Session Description Protocol in general.  See [SCTP] for security
   and other considerations relating to the Stream Transmission Control
   Protocol in general.  There are no new security considerations
   introduced by these protocol identifiers and attributes.

13 IANA Considerations

   IANA registration is needed for the following three SDP transport
   identifiers: "SCTP", "U-SCTP" & "RTP/AVP-USCTP".

Fairlie-Cuninghame      Expires November 2001                       15
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001


   This SCTP data chunk payload identifier value of 0x000A needs to be
   registered and reserved for RTP & RTCP data chunk payloads.

   This document also introduces four SDP attributes that are valid
   when the above transport identifiers are used in media
   announcements, these are "sctpPort", "sctpAssn", "sctpOptn" &
   "sctpStrm".

   Lastly, this document introduces six SDP format identifiers for the
   SCTP adaptation layers being developed by the SIGTRAN working group:
   "iua", "m2ua", "m2pa", "m3ua", "sua" & "v5ua".  These format
   identifiers are only relevant to the "SCTP" transport identifier.

Acknowledgements

   The author would like to thank Jon Berger for his valuable comments
   and suggestions.

References

   [AVP]       H. Schulzrinne, "RTP Profile for Audio and Video
               Conferences with Minimal Control", RFC1890, January 1996

   [COMEDIA]   D. Yon, "Connection-Oriented Media Transport in SDP",
               Work in Progress, IETF draft

   [IUA]       K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom,
               "ISDN Q.921-User Adaptation Layer", RFC 3057, February
               2001

   [M2PA]      T. George, R. Dantu, M. Kalla, H. Schwarzbauer, G.
               Sidebottom, K. Morneault, "SS7 MTP2-User Peer-to-Peer
               Adaptation Layer", Work in Progress, IETF draft

   [M2UA]      K. Morneault, R. Dantu, G. Sidebottom, T. George,
               B.Bidulock, J. Heitz, "SS7 MTP2-User Adaptation Layer",
               Work in Progress, IETF draft

   [M3UA]      G. Sidebottom et al, "SS7 MTP3-User Adaptation Layer",
               Work in Progress, IETF draft

   [MGCP]      M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett,
               "Media Gateway Control Protocol", RFC2705, October 1999

   [KEYWORDS]  S. Bradner, "Key words for use in RFCs to indicate
               Requirement levels", BCP 14, RFC 2119, March 1997

   [RTP]       Schulzrinne, H., Casner, S., Frederick, R. and V.
               Jacobson, "RTP: a transport protocol for real-time
               applications", RFC 1889, Internet Engineering Task
               Force, January 1996


Fairlie-Cuninghame      Expires November 2001                       16
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   [SCTP]      R. Stewart, M. A. Ramalho, Q. Xie, P. Conrad, M. Rose,
               "Stream Control Transmission Protocol", RFC 2960,
               October 2000

   [SCTPAS]    L. Coene et al, "Stream Control Transmission Protocol
               Applicability Statement", Work in progress, IETF draft

   [SDP]       M. Handley, V. Jacobson, "SDP: Session Description
               Protocol", RFC 2327, April 1998

   [SIP]       M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg,
               "SIP: Session Initiation Protocol", RFC 2543, March 1999

   [SUA]       J. Loughney et al, "SS7 SCCP-User Adaptation Layer",
               Work in Progress, IETF draft

   [USCTP]     Q. Xie, R. Stewart, C. Sharp, I. Rytina, "SCTP
               Unreliable Data Mode Extension", Work in Progress, IETF
               draft

   [UTF-8]     F. Yergeau, "UTF-8, a transformation format of Unicode
               and ISO 10646", RFC 2044, October 1996

   [V5UA]      E. Weilandt, F. Ergincan, S. Rao, "V5.2-User Adaption
               Layer", Work in Progress, IETF draft

Author's Address

   Robert Fairlie-Cuninghame
   Nuera UK, Ltd.
   50 Victoria Rd
   Farnborough
   Hants GU14 7PG
   UK

   Phone: +44-1252-548-200
   Email: rfairlie@nuera.com

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be

Fairlie-Cuninghame      Expires November 2001                       17
INTERNET-DRAFT   draft-fairlie-mmusic-sdp-sctp-00.txt         May 2001

   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."










































Fairlie-Cuninghame      Expires November 2001                       18