Internet DRAFT - draft-fairlie-mmusic-sdp-sctp
draft-fairlie-mmusic-sdp-sctp
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
