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 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 identifier is equal to one of the identifiers specified in this document. For SCTP media announcements, the SDP protocol-specific 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= where is one of the transport identifiers listed in Section 3.2.2. The semantics of the , and values are unchanged from the basic media announcement defined in [SDP]. The semantics of the 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 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 value equal to the stream number plus one would suffice as a simple mapping scheme.] An 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