idnits 2.17.1 draft-fairlie-mmusic-sdp-sctp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 47 characters in excess of 72. ** The abstract seems to contain references ([USCTP], [SCTP], [SDP], [UTF-8], [SCTPAS], [COMEDIA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2001) is 8379 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'MGCP' is defined on line 845, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1890 (ref. 'AVP') (Obsoleted by RFC 3551) -- Possible downref: Non-RFC (?) normative reference: ref. 'COMEDIA' ** Obsolete normative reference: RFC 3057 (ref. 'IUA') (Obsoleted by RFC 4233) -- Possible downref: Non-RFC (?) normative reference: ref. 'M2PA' -- Possible downref: Non-RFC (?) normative reference: ref. 'M2UA' -- Possible downref: Non-RFC (?) normative reference: ref. 'M3UA' ** Obsolete normative reference: RFC 2705 (ref. 'MGCP') (Obsoleted by RFC 3435) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2960 (ref. 'SCTP') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. 'SCTPAS' ** Obsolete normative reference: RFC 2327 (ref. 'SDP') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. 'SUA' -- Possible downref: Non-RFC (?) normative reference: ref. 'USCTP' ** Obsolete normative reference: RFC 2044 (ref. 'UTF-8') (Obsoleted by RFC 2279) -- Possible downref: Non-RFC (?) normative reference: ref. 'V5UA' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Fairlie-Cuninghame 2 Document: draft-fairlie-mmusic-sdp-sctp-00.txt Nuera Communications 3 Expires November 2001 May 2001 5 Guidelines for specifying SCTP-based media transport using SDP 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at: 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at: 27 http://www.ietf.org/shadow.html 29 Copyright (C) The Internet Society (2001). All Rights Reserved. 31 Abstract 33 This document describes a set of guidelines for using the Session 34 Description Protocol (SDP) to specify media transport using the 35 Stream Control Transmission Protocol (SCTP). It defines three new 36 SDP transport identifiers: "SCTP", "USCTP" and "RTP/AVP-USCTP" that 37 provide reliable, unreliable and RTP-based unreliable media 38 transport using SCTP. The document also provides guidelines for 39 establishing and managing the SCTP associations used to provide the 40 media transport. 42 Fairlie-Cuninghame 1 43 Introduction 45 The Session Description Protocol [SDP] provides a general-purpose 46 format for describing multimedia sessions in announcements or 47 invitations. SDP uses an entirely textual data format (the US-ASCII 48 subset of [UTF-8]) to maximize portability among transports. SDP 49 does not define a protocol, but only the syntax to describe a 50 multimedia session with sufficient information to discover and 51 participate in that session. Session descriptions may be sent using 52 any number of existing application protocols for transport (e.g., 53 SAP, SIP, MGCP, RTSP, email, HTTP, etc.). 55 The Stream Control Transmission Protocol [SCTP] is a reliable 56 transport protocol operating on top of a connectionless packet 57 network such as IP. It offers reliable, non-duplicated transfer of 58 user datagrams along with many additional features such as data 59 bundling, fragmentation, fault-tolerance for multi-homed endpoints 60 and protection from certain flooding and masquerade attacks. An 61 extension to the base SCTP protocol, known as U-SCTP, provides an 62 unreliable transport mechanism over SCTP [USCTP]. An SCTP 63 association is established through a four-way handshake between two 64 SCTP endpoints; the association provides up to 65536 unidirectional 65 transport streams in each direction. 67 The base SDP specification only describes transport identifiers for 68 UDP ("udp") and RTP over UDP ("RTP/AVP"). This document provides 69 guidelines for using the session description protocol to describe 70 media sessions using SCTP, U-SCTP or RTP over U-SCTP as the 71 transport protocol. The guidelines in this document apply to 72 sessions consisting of unicast media announcements in IP based 73 networks. In addition to providing a mechanism for identifying SCTP 74 transport streams, the guidelines also provide a mechanism to 75 reliably establish and configure the SCTP associations between two 76 applications. 78 Motivation 80 The Stream Control Transmission Protocol provides a number of 81 advantages over basic TCP transport. These advantages (including 82 those listed briefly in the introduction) are discussed in detail in 83 the SCTP specification [SCTP] and the SCTP applicability statement 84 [SCTPAS]. The Unreliable-SCTP extension provides many of the same 85 advantages over basic UDP transport. Media transport, such as that 86 described by SDP, has traditionally used connectionless, unreliable 87 transport protocols such as UDP; interestingly, U-SCTP separates the 88 unreliable and connectionless aspects, that is, U-SCTP provides an 89 unreliable but (somewhat) connection-oriented transport mechanism. 91 The use of SDP to negotiate media sessions with connection-oriented 92 transport protocols such as TCP and TLS is described in [COMEDIA]. 93 However there are a number of important differences between SCTP and 94 the connection-oriented transport protocols referenced in that 95 document: 97 Fairlie-Cuninghame Expires November 2001 2 98 - SCTP establishes associations between SCTP endpoints rather than 99 between the individual media endpoints described in session 100 descriptions. 101 - Once an SCTP association has been established, data can be sent or 102 received on any SCTP stream without further negotiation. 103 - The information required to reliably establish an SCTP association 104 is greater than the information required to identify the media 105 endpoint. 106 - SCTP streams are unidirectional and not bidirectional. 107 - As SCTP uses chunk bundling and active path probing, it may be 108 highly desirable (although not necessary) to establish only a 109 single SCTP association between two endpoints and make use of 110 multiple streams within the association. 112 For these reasons SCTP requires its own SDP transport identifier 113 guidelines (as provided by this document) and replaces the SCTP 114 transport identifier formerly defined in earlier revisions of the 115 [COMEDIA] draft. 117 The typical traffic characteristics of RTP-based media (usually 118 consisting of small, delay-sensitive packets) make SCTP transport 119 especially attractive when there are multiple streams sharing the 120 same SCTP association. Chunk bundling can be used to substantially 121 improve bandwidth efficiency for multiple RTP streams. On low speed 122 links the data fragmentation facility becomes useful in reducing 123 arrival jitter in RTP media if the SCTP association is shared with 124 data or session control traffic (typically containing larger, more 125 variable-sized packets). As for any traffic type, SCTP can provide 126 a degree of fault-tolerance when used with multi-homed endpoints. 128 The current "RTP/AVP" profile lacks any mechanism to restrict or 129 allow the pre-determination of the source address of RTP packets. 130 This poses a number of problems for the security of RTP media and 131 firewall traversal. "RTP/AVP-USCTP" by its inherent nature only 132 allows RTP media to be received on established SCTP associations. 133 Whilst the transport profile does not impose restrictions on the 134 remote SCTP endpoint for any association, the profile does however 135 optionally allow the establishment of SCTP associations to be 136 externally controlled. In this manner, it is possible that this 137 might be used to provide some level of protection from blind 138 masquerade attacks on RTP media and assist in firewall traversal (at 139 the expense of dynamic association negotiation). This is not 140 necessarily the best approach but does provide a possible avenue for 141 small statically configured networks. 143 1 Terminology 145 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 146 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 147 and "OPTIONAL" are to be interpreted as described in RFC 2119 148 [KEYWORDS]. 150 Fairlie-Cuninghame Expires November 2001 3 151 2 Definitions 153 2.1 Identifying and specifying SCTP endpoints 155 An SCTP transport address is defined as an IP address (or hostname) 156 and SCTP port. An SCTP endpoint is defined as a set of SCTP 157 transport addresses having the same SCTP port value; furthermore, 158 SCTP transport addresses may not be shared between SCTP endpoints. 159 A single SCTP transport address therefore uniquely identifies the 160 SCTP endpoint to which it belongs. An SCTP association is defined 161 by the two SCTP endpoints present in the association. 163 For multi-homed SCTP endpoints, the information required to reliably 164 create an association to an endpoint is greater than the information 165 required to identify the endpoint. Specifically, although a single 166 SCTP transport address is sufficient to identify any multi-homed 167 SCTP endpoint, all transport addresses must be known to reliably 168 create an association to it. This is highlighted by considering the 169 situation where a subset of the endpoint's transport addresses are 170 unreachable when an association must be established. Assuming that 171 at least one transport address is reachable, then in general, an 172 association cannot be reliably established unless all transport 173 addresses are known. 175 Thus, this document uses the phrase "to identify an SCTP endpoint" 176 to mean that only enough information is available to uniquely 177 identify the SCTP endpoint but not necessarily to fully define it. 178 Hence, the endpoint can be identified, however, it may not be 179 possible to reliably create a new association to this endpoint. 181 The phrase "to specify an SCTP endpoint" is used to mean that enough 182 information is provided to both fully define the SCTP endpoint and 183 to reliably create a new association to the endpoint. 185 3 Using SDP to describe SCTP endpoints and streams 187 Each SCTP endpoint has control over the properties and usage of the 188 outbound (unidirectional) streams in its associations; likewise, the 189 properties of the inbound streams are controlled by the remote SCTP 190 endpoint (cf. [USCTP]). This is an important point to note as SDP 191 session advertisements only describe the way in which media can be 192 sent to the issuing application, that is, SDP specifies which 193 inbound streams must be used for media transport. This idea drives 194 the underlying paradigm for these guidelines: the remote application 195 is responsible for taking whatever actions are required to create or 196 configure a media path to the issuing application. This rule is 197 slightly complicated by the fact that the remote application may 198 have to wait for the issuing application to INITiate an association 199 (similar to other connection-based media transport protocols, as 200 discussed in [COMEDIA]). 202 SCTP media announcements use two basic pieces of information to 203 identify the SCTP stream on which media will be expected: the SCTP 205 Fairlie-Cuninghame Expires November 2001 4 206 endpoint and the stream number. In SDP, the information required to 207 identify these two entities will be conveyed by two new SDP 208 attributes: "sctpPort" and "sctpStrm" which qualify the connection 209 information ("c=") and media announcement ("m=") SDP components 210 respectively. 212 Generally, existing SCTP associations SHOULD be used in preference 213 to creating new associations. However this may not be possible if 214 the existing association's properties are inconsistent with the SDP 215 media announcements and reconfiguration of the association is not 216 possible. When a new association must be established, the set of 217 information used/supplied by an application to create/accept an 218 association is as follows: 219 - A list of remote transport addresses used for creating an 220 association. 221 - An indication of whether the issuing application will INITiate or 222 wait for an association. 223 - The number of inbound streams requested by the issuing 224 application. 225 - The type of the inbound streams (SCTP or U-SCTP). 226 - The set of extensions/capabilities implemented by the SCTP stack. 227 - Optionally, the first transport address to try when attempting a 228 connection. 230 This information is conveyed in two new SDP attributes: "sctpAssn" 231 and "sctpOptn". 233 3.1 SCTP connection information ("c=") 235 The primary role of the SCTP connection information component is to 236 identify (and possibly specify) an SCTP endpoint. The single IP 237 address normally present in a connection information ("c=") line is 238 not sufficient to identify an SCTP endpoint. The "sctpPort" 239 attribute is introduced in this document to provide the additional 240 SCTP port information required for SCTP endpoint identification. 242 SCTP connection information ("c=") components MUST include the 243 "sctpPort" attribute ("a=") in the same media or session-level 244 section as the connection information ("c=") line. In other words, 245 a connection information ("c=") line refers to an SCTP endpoint if 246 the "sctpPort" attribute is present in the same media or session- 247 level section. Additionally, any media announcements ("m=") 248 referencing the SCTP connection information ("c=") line MUST be an 249 SCTP media announcement (and vice versa). 251 The "sctpAssn" attribute further specifies the SCTP endpoint (and 252 the desired association) identified by the SCTP connection 253 information ("c="). This attribute may be present in any section 254 where the "sctpPort" attribute is present. The semantics of this 255 attribute are defined in Section 4.1. 257 If the address specified in the connection information ("c=") line 258 is equal to zero and the "sctpPort" attribute is present then it is 260 Fairlie-Cuninghame Expires November 2001 5 261 still treated as a valid SCTP connection information ("c=") 262 component but any associated media announcements should be treated 263 as "on hold" or inactive. 265 The IP address in the connection information ("c=") SHOULD be set 266 equal to the primary address of the SCTP endpoint but applications 267 MUST be able to identify the SCTP endpoint using any constituent 268 SCTP transport address. 270 3.2 SCTP media announcements ("m=") 272 An SCTP media announcement is defined to be any SDP media 273 announcement ("m=") where the identifier is equal to one 274 of the identifiers specified in this document. For SCTP media 275 announcements, the SDP protocol-specific value is defined to 276 be a 32-bit number that will be referred to as the SCTP media 277 "announcement identifier" and is described below. 279 Therefore the format of an SCTP media announcement is 281 m= 283 where is one of the transport identifiers listed in 284 Section 3.2.2. The semantics of the , and values are unchanged from the basic media announcement defined 286 in [SDP]. The semantics of the field is described 287 in the section below. 289 All SCTP media announcements MUST include the "sctpStrm" attribute 290 as a media-level attribute. This attribute is described in Section 291 4.4. 293 3.2.1 Semantics of the SCTP media announcement identifier 295 The value of the is chosen by the application to 296 be a non-zero value (for accepted announcements) that uniquely maps 297 to the specified stream for the lifetime of the media session. This 298 preserves the property exhibited by normal UDP or TCP port values 299 whereby each media announcement uses a different port value within 300 the same connection information ("c=") component. [An 301 value equal to the stream number plus one would 302 suffice as a simple mapping scheme.] 304 An value of zero has special significance in some 305 application protocols ([SIP] for instance) and so this value MUST 306 not be used in accepted or offered media announcements. 308 3.2.2 SCTP transport identifiers 310 This document introduces three new media transport identifiers: 311 "SCTP", "USCTP", and "RTP/AVP-SCTP". Each is described below: 313 Fairlie-Cuninghame Expires November 2001 6 314 3.2.2.1 "SCTP" 316 The "SCTP" transport identifier provides a reliable, ordered or 317 unordered datagram service over SCTP as described in the base SCTP 318 specification [SCTP]. This transport identifier is analogous to the 319 transport service provided by "TCP" transport identifier described 320 in [COMEDIA]. 322 It is up to the sending application to determine whether "SCTP" 323 datagrams should be transported in an ordered or unordered manner 324 and this may chosen on a per-packet basis as described in [SCTP]. 326 3.2.2.2 "USCTP" 328 The "USCTP" transport identifier provides an unreliable, ordered or 329 unordered datagram service over U-SCTP. The U-SCTP extension to 330 SCTP is described in [USCTP]. This transport identifier corresponds 331 to the "udp" transport service described in [SDP]. 333 It is up to the sending application to determine whether "USCTP" 334 datagrams should be transported in an ordered or unordered manner 335 and this may chosen on a per-packet basis as described in [USCTP]. 337 3.2.2.3 "RTP/AVP-USCTP" 339 The "RTP/AVP-USCTP" transport identifier provides an unreliable, 340 unordered datagram service (using U-SCTP) for RTP media conforming 341 to the RTP Profile for Audio and Video Conferences with Minimal 342 Control [AVP]. As such, "RTP/AVP-USCTP" corresponds to the 343 "RTP/AVP" transport service which uses UDP to provide the unreliable 344 datagram transport. 346 The RTP profile [AVP] states that definitions in the profile do not 347 preclude the use of other lower layer protocols and that RTP uses 348 the SSRC field to identify media sources rather than transport 349 addresses. [The selection of the CNAME record in RTCP SDES records 350 for multi-homed hosts is beyond the scope of this document.] 352 For the "RTP/AVP-USCTP" transport identifier, RTP packets are sent 353 on outbound SCTP streams rather than to destination UDP ports, so 354 all mention of RTP ports in [RTP] and [AVP] should instead be 355 interpreted as referring to an SCTP stream number. 357 As such, all RTP datagrams MUST be carried on an even numbered 358 stream and all RTCP datagrams are carried on the next (odd-numbered) 359 stream. "RTP/AVP-USCTP" also differs in the range of the valid 360 stream numbers - there is no lower limit due to reserved UDP ports, 361 that is, any even U-SCTP stream pair in an association may be used 362 to carry RTP/RTCP (including the zero stream). 364 When sending any RTP packet over U-SCTP the unordered bit MUST be 365 set in the data chunk (RTP packets contain their own timestamp). 366 The payload identifier of the data chunk MUST be set to 0x000A for 368 Fairlie-Cuninghame Expires November 2001 7 369 all RTP and RTCP packets transmitted under this transport 370 identifier. 372 4 New SDP attribute semantics ("a=") 374 4.1 Semantics of the "sctpPort" attribute 376 The "sctpPort" attribute specifies that the associated connection 377 information ("c=") line refers to an SCTP endpoint. In other words, 378 the "sctpPort" attribute can only be present as a session-level 379 attribute if a session-level connection information ("c=") line 380 exists and can only be present as a media-level attribute if a 381 media-level connection information ("c=") line exists. The 382 "sctpPort" attribute specifies the local SCTP port to be used by the 383 SCTP endpoint. An endpoint can thus be identified by the 384 combination of the SCTP port and the address information in the 385 connection information ("c=") line (or the "sctpAssn" attribute 386 described below). 388 The format of the "sctpPort" attribute is as follows: 390 sctpport-attribute = "sctpPort:" port-number 392 port-number = 1*DIGIT 394 4.2 Semantics of the "sctpAssn" attribute 396 The "sctpAssn" attribute is an optional but RECOMMENDED attribute 397 that allows the SCTP association to be dynamically negotiated. 399 The format of the "sctpAssn" attribute is: 401 sctpassn-attribute = "sctpAssn:" transport-address-list 402 SP number-inbound-streams 403 SP inbound-usctp-stream-list 404 SP direction 405 [ SP initial-transport-address ] 407 transport-address-list = (IPv4address | Ipv6reference) 408 *("," IPv4address|Ipv6reference) 409 | hostname 411 number-inbound-streams = 1*DIGIT 413 inbound-usctp-stream-list = ( 1*DIGIT "-" 1*DIGIT) 414 *("," 1*DIGIT "-" 1*DIGIT) ) 415 | "-" | "x" 417 direction = "passive" | "active" [":" source-port] 418 | "both" [":" source-port] 420 source-port = 1*DIGIT 422 Fairlie-Cuninghame Expires November 2001 8 423 initial-transport-address = (IPv4address | Ipv6reference) 425 The sctpassn-attribute MUST NOT contain spaces except where 426 explicitly noted above. 428 - The transport-address-list specifies a list of IP addresses or a 429 single fully qualified DNS hostname that make up the SCTP 430 endpoint. An application may send an INIT to any of these 431 addresses to create an association (direction parameter 432 permitting). The list SHOULD include all transport addresses used 433 by the endpoint and the primary address SHOULD occur first. The 434 address in the connection information ("c=") line MUST be present 435 in the transport-address-list. 436 - The number-inbound-streams value specifies the number of inbound 437 streams the issuing application desires. This value is also used 438 when generating the INIT or INIT_ACK chunks during association 439 negotiation. 440 - The inbound-usctp-stream-list specifies which of the inbound 441 streams are to be configured as U-SCTP. If the issuing 442 application does not support U-SCTP then it MUST place an "x" in 443 this field. If the issuing application does support U-SCTP but 444 does not want to configure any U-SCTP streams then it places a "-" 445 in this field. An example of a valid inbound-usctp-stream-list 446 value for a 100 inbound streams is "0-50,75-99". 447 - The direction and source-port fields are based on the "direction" 448 attribute described in [COMEDIA]. The direction field defined 449 here has the same meaning as in [COMEDIA], however, it is only 450 relevant in establishing an SCTP association and has no 451 significance for each individual media announcement. The optional 452 source-port field specifies the source SCTP port that will be used 453 when sending an INIT chunk; this corresponds to the source port 454 field described in [COMEDIA]. 455 - The initial-transport-address indicates the address the remote 456 application MAY initially send an INIT chunk to. An application 457 SHOULD generate this value when it knows that the primary 458 transport address is unreachable from the remote application. If 459 the transport-address-list field is not a DNS hostname then the 460 address in initial-transport-address MUST be one of the addresses 461 in this list. Otherwise, if the transport-address-list field is a 462 DNS hostname then the initial-transport-address value MAY still be 463 used as the initial destination address; however, if this 464 association attempt fails a normal DNS lookup MUST be performed. 466 If the "sctpAssn" attribute is omitted in the remote application's 467 session advertisement, then the local application must either: 468 use static or external configuration information to initiate the 469 SCTP association, or rely on the SCTP association being already 470 established. 472 Applications SHOULD treat as an error the situation where an SCTP 473 association cannot be established, for instance, when the "sctpAssn" 474 attribute is not present and external configuration or an existing 475 association does not exist. Applications MUST NOT guess endpoint 477 Fairlie-Cuninghame Expires November 2001 9 478 address information from the connection information (c=) line 479 address, that is, if the "sctpAssn" attribute is missing and there 480 is no external configuration then the application MUST NOT attempt 481 to INITiate an association. 483 An application MAY ignore the "sctpAssn" attribute in a session 484 description if an association to the remote SCTP endpoint 485 (identified by the connection information ("c=") address and 486 "sctpPort" value) is already established and has the correct inbound 487 stream type for all media announcements using the endpoint. 489 4.3 Semantics of the "sctpOptn" attribute 491 The "sctpOptn" attribute lists the SCTP extensions implemented by 492 the issuing application's SCTP stack. The "sctpOptn" attribute is 493 an optional attribute that can occur anywhere that the "sctpAssn" 494 can occur. It is not necessary to indicate support of the U-SCTP 495 extension in the "sctpOptn" attribute as this can be determined from 496 the "sctpAssn" attribute. 498 sctpoptn-attribute = "sctpOptn:" sctp-option 499 *("," sctp-option) 501 sctp-option = token 503 4.4 Semantics of the "sctpStrm" attribute 505 The "sctpStrm" attribute MUST be present in every SCTP media 506 announcement and cannot appear as a session-level attribute. The 507 "sctpStrm" attribute specifies the stream number on which the 508 application expects to receive media for the media announcement 509 ("m="). 511 The format of the "sctpStrm" attribute is 513 sctpstrm-attribute = "sctpStrm:" stream-number 514 [ "/" number-of-streams ] 516 stream-number = 1*DIGIT 518 number-of-streams = 1*DIGIT 520 - The stream-number MUST have a value between 0 and the configured 521 number of inbound streams minus one. 522 - The number-of-streams value is the number of contiguous streams 523 used by this media announcement. 525 SCTP media announcements using the "RTP/AVP-USCTP" transport 526 identifier must specify an even stream number as described in 527 Section 3.2.2.3. 529 5 Handling of existing SDP parameters 531 Fairlie-Cuninghame Expires November 2001 10 532 5.1 "recvonly" & "sendonly" attributes. 534 Many protocols use SDP to form logical bidirectional media paths 535 using two session descriptions (one issued by each endpoint). SDP 536 allows an application to configure a media path to be unidirectional 537 at the application level by specifying the "sendonly" or "recvonly" 538 attributes in at least one session description. 540 As the "sendonly" or "recvonly" attributes refer only to the 541 application-level media path, valid media announcements are still 542 generated in both directions, however, the exact definition of 543 "sendonly" and "recvonly" is application specific. Normally (for 544 example in SIP and MGCP), this means that any media payload packets 545 received in the unused direction are discarded. For "RTP/AVP-USCTP" 546 streams it should be remembered that RTCP reports MUST still be 547 generated and sent in the reverse (unused) direction (as for 548 "RTP/AVP"). 550 6 Guidelines for opening SCTP associations 552 An application will normally open a new association when a media 553 announcement is received identifying an SCTP endpoint for which a 554 usable association is not established (or not in the process of 555 being established). In this context a usable association is an 556 association with a usable stream that is connected to the remote 557 SCTP endpoint specified in the remote session description. For 558 bidirectional media sessions using two complementary session 559 descriptions, a usable association is also an association with a 560 usable stream that is connected to the local SCTP endpoint of the 561 corresponding local session description. 563 The direction field in the "sctpAssn" attribute may however force 564 the application to wait for the remote application to INITiate the 565 association. If both the local and remote application have 566 generated complementary session descriptions, then it is RECOMMENDED 567 that the initial association be established between the two 568 endpoints described in the session descriptions. New associations 569 SHOULD be established so as to satisfy the requirements of all media 570 announcements referencing the local and remote endpoints. 572 If an address is present in the initial-transport-address field and 573 the session description was issued relatively recently then this 574 address SHOULD be used for the initial INIT chunk destination when 575 attempting to open an SCTP association; otherwise the primary 576 address SHOULD be used initially. If an association attempt to the 577 initial address fails, the application MUST attempt to establish an 578 association with the other known transport addresses. If the 579 ASSOCIATE primitive of the SCTP implementation only accepts a single 580 destination address then the application MUST provide this fault- 581 tolerant behavior. The application SHOULD configure a small number 582 of retransmits for the INIT chunk to ensure that the alternative 583 addresses can be tried in a timely manner. 585 Fairlie-Cuninghame Expires November 2001 11 586 If multiple associations are established using this method, then the 587 application SHOULD choose only one association and terminate the 588 others. It is up to the application to decide whether or not to 589 accept an association where the negotiated remote transport address 590 set does not match the address set in the remote session 591 description. 593 When INITiating an association, the maximum number of outbound 594 streams specified in the INIT chunk SHOULD be set to the 595 application's implementation or pre-configured maximum value. If 596 the application expects to receive media on the local SCTP endpoint 597 then the maximum number of inbound streams specified in the INIT 598 chunk SHOULD be set to the number-inbound-streams value specified in 599 the "sctpAssn" attribute of the local session description. 601 When accepting an association, the maximum number of outbound 602 streams specified in the INIT .ACK chunk SHOULD be set to the minimum 603 of the number of inbound streams specified in the INIT chunk and the 604 implementation or pre-configured maximum value. If the application 605 expects to receive media on the local SCTP endpoint then the maximum 606 number of inbound streams specified in the INIT .ACK chunk SHOULD be 607 set to the minimum of the number of outbound streams specified in 608 the INIT chunk and the number-inbound-streams value specified in the 609 "sctpAssn" attribute of the local session description. 611 In this way the negotiated number of SCTP streams in each used 612 direction is equal to the minimum of the requested value and the 613 remote implementation or pre-configured maximum value. The behavior 614 when the remote application indicates a maximum number of outbound 615 streams that is smaller than the requested number of inbound streams 616 is application specific. 618 An application MAY provide hints that an association SHOULD be 619 opened/modified without announcing media by presenting a session 620 description with a session-level SCTP connection information ("c=") 621 line but no media announcements ("m="). 623 7 Guidelines for modifying or adding SCTP associations 625 It is the sender's responsibility to generate an association with 626 the appropriate properties to satisfy the remote session 627 description. This may either require that a new association is 628 created with the desired stream properties or that an existing 629 association is modified to become consistent. Adding or restarting 630 an association may be required when the number of streams or the 631 type of streams (reliable or unreliable) in the existing 632 associations differs to what is being requested by the media 633 announcements in the remote session description. 635 Restarting (rather than adding) an association SHOULD be performed 636 when an application wishes to maintain a single association with the 637 remote application. However, restarting an association may result 638 in a temporary disruption to media flow during the restart. 640 Fairlie-Cuninghame Expires November 2001 12 641 If an application chooses to replace the association currently being 642 used to send media then the application should open a new 643 association in accordance with the guidelines outlined in the 644 previous section. Additionally, the new association SHOULD satisfy 645 the requirements of all media announcements using the local and 646 remote endpoints. 648 8 Guidelines for sending and accepting data on SCTP associations 650 If only one application has issued a session description then the 651 other application is limited to sending media on associations where 652 the remote SCTP endpoint matches the endpoint specified in the 653 remote media announcement. However when both applications have 654 issued complementary session descriptions (to establish 655 bidirectional media sessions) then an application may send media on 656 any association where either the local or remote endpoint matches an 657 SCTP endpoint identified in the corresponding session description. 659 Once an application begins sending media on a particular association 660 it SHOULD NOT change to sending on a different association whilst 661 the current association remains established. This ensures that end- 662 to-end ordering is maintained and that race conditions for closing 663 streams do not occur. It does however mean that bandwidth 664 efficiency (from the chunk bundling of data and SACK's) is reduced 665 when associations are not restarted as described in the previous 666 section. 668 An application SHOULD accept data on any association with the local 669 SCTP endpoint as long as the stream type is consistent with the 670 relevant media announcement. For bidirectional media sessions where 671 the "sctpAssn" attribute was placed in the local session 672 description, the application SHOULD also accept data on any 673 association connected to the remote SCTP endpoint in the 674 corresponding remote session description. 676 9 Guidelines for closing an SCTP association 678 If an application has multiple associations established for any 679 media announcement, the application MAY choose to terminate the 680 unused associations to reclaim the resources associated with them. 681 However, in this case, the application SHOULD NOT close any 682 association where data has been sent or received for an active media 683 announcement. 685 An application MAY indicate that all associations to a local SCTP 686 endpoint are no longer required by presenting a session description 687 containing a session-level SCTP connection information ("c=") line 688 with a zero address and no media announcements ("m="). In this case 689 the SCTP endpoint is identified using the "sctpAssn" attribute. How 690 these indications are actually used (if at all) will depend on the 691 application in which SDP is used - SDP merely provides a means to 692 convey this information. 694 Fairlie-Cuninghame Expires November 2001 13 695 10 New format identifiers for the "SCTP" transport identifier 697 The IETF SIGTRAN working group has developed a number of adaptation 698 layers for transporting telephony signaling over SCTP. As SDP can 699 also be conveniently used to describe these signaling connections, 700 SDP format identifiers will be defined for these SCTP adaptation 701 layers. 703 SDP format identifiers for the "SCTP" transport identifier: 705 "iua" - ISDN Q.921 User Adaptation Layer [IUA] 706 "m2ua" - MTP2 User Adaptation Layer [M2UA] 707 "m2pa" - MTP2 User Peer-to-peer Adaptation Layer [M2PA] 708 "m3ua" - MTP3 User Adaptation Layer [M3UA] 709 "sua" - SS7 SCCP User Adaptation Layer [SUA] 710 "v5ua" - V5.2 User Adaptation Layer [V5UA] 712 11 SDP Examples 714 The following examples demonstrate how the above guidelines may be 715 used to describe SCTP media transport. 717 For clarity minimal values are used for "o=", "s=", "t=" 718 components. In normal applications the appropriate values should be 719 used. 721 11.1 Minimal SCTP session description (no association information) 723 v=0 724 o=- 0 0 IN IP4 10.0.0.1 725 s=- 726 c=IN IP4 10.0.0.1 727 t=0 0 728 a=sctpPort:5000 729 m=audio 1 RTP/AVP-USCTP 0 8 730 a=sctpStrm:0 731 m=video 2 RTP/AVP-USCTP 31 732 a=sctpStrm:2 734 This example uses a session level SCTP connection information ("c=") 735 component with two SCTP media announcements. As the "sctpAssn" 736 attribute is missing, the applications can only use existing or 737 externally configured SCTP associations for media transport. 739 11.2 Multiple SCTP associations 741 v=0 742 o=- 0 0 IN IP4 10.0.0.1 743 s=- 744 t=0 0 745 m=control 10 SCTP m2ua 746 c=IN IP4 10.0.0.1 748 Fairlie-Cuninghame Expires November 2001 14 749 a=sctpPort:6000 750 a=sctpAssn:10.0.0.1,10.0.0.2 10 - both:11000 10.0.0.2 751 a=sctpStrm:0 752 m=audio 20 RTP/AVP-USCTP 0 8 753 c=IN IP4 10.0.0.1 754 a=sctpPort:5000 755 a=sctpAssn:10.0.0.1,10.0.0.2 100 0-99 both:10000 10.0.0.2 756 a=sctpStrm:0 758 This example uses two separate SCTP associations. One association 759 is configured to have 10 inbound SCTP streams and the other is 760 configured to have 100 inbound U-STCP streams. Both associations 761 will attempt to establish the association but will also accept an 762 inbound association. In both cases the issuing application is 763 indicating that the remote application should use 10.0.0.2 as the 764 destination for the initial INIT chunk. The SCTP implementation has 765 not indicated that it supports any extensions beside U-SCTP. 767 11.3 Mixed media announcements 769 v=0 770 o=- 0 0 IN IP4 bob.company.com 771 s=- 772 c=IN IP4 bob.company.com 773 t=0 0 774 m=data 10000 TCP t38 775 a=direction:both 776 m=audio 1 RTP/AVP-USCTP 0 777 c=IN IP4 bob.company.com 778 b=AS:64 779 a=sctpPort:10001 780 a=sctpAssn:bob.company.com 100 50-99 active 781 a=sctpOptn:addip,srwnd 782 a=sctpStrm:50 784 This example uses one TCP and one SCTP media announcement. The SCTP 785 announcement indicates that the issuing application will INITiate an 786 association to SCTP endpoint specified in the remote applications 787 session description. The "sctpOptn" attribute values listed in this 788 example are as yet undefined. 790 12 Security Considerations 792 See [SDP] for security and other considerations relating to the 793 Session Description Protocol in general. See [SCTP] for security 794 and other considerations relating to the Stream Transmission Control 795 Protocol in general. There are no new security considerations 796 introduced by these protocol identifiers and attributes. 798 13 IANA Considerations 800 IANA registration is needed for the following three SDP transport 801 identifiers: "SCTP", "U-SCTP" & "RTP/AVP-USCTP". 803 Fairlie-Cuninghame Expires November 2001 15 804 This SCTP data chunk payload identifier value of 0x000A needs to be 805 registered and reserved for RTP & RTCP data chunk payloads. 807 This document also introduces four SDP attributes that are valid 808 when the above transport identifiers are used in media 809 announcements, these are "sctpPort", "sctpAssn", "sctpOptn" & 810 "sctpStrm". 812 Lastly, this document introduces six SDP format identifiers for the 813 SCTP adaptation layers being developed by the SIGTRAN working group: 814 "iua", "m2ua", "m2pa", "m3ua", "sua" & "v5ua". These format 815 identifiers are only relevant to the "SCTP" transport identifier. 817 Acknowledgements 819 The author would like to thank Jon Berger for his valuable comments 820 and suggestions. 822 References 824 [AVP] H. Schulzrinne, "RTP Profile for Audio and Video 825 Conferences with Minimal Control", RFC1890, January 1996 827 [COMEDIA] D. Yon, "Connection-Oriented Media Transport in SDP", 828 Work in Progress, IETF draft 830 [IUA] K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom, 831 "ISDN Q.921-User Adaptation Layer", RFC 3057, February 832 2001 834 [M2PA] T. George, R. Dantu, M. Kalla, H. Schwarzbauer, G. 835 Sidebottom, K. Morneault, "SS7 MTP2-User Peer-to-Peer 836 Adaptation Layer", Work in Progress, IETF draft 838 [M2UA] K. Morneault, R. Dantu, G. Sidebottom, T. George, 839 B.Bidulock, J. Heitz, "SS7 MTP2-User Adaptation Layer", 840 Work in Progress, IETF draft 842 [M3UA] G. Sidebottom et al, "SS7 MTP3-User Adaptation Layer", 843 Work in Progress, IETF draft 845 [MGCP] M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, 846 "Media Gateway Control Protocol", RFC2705, October 1999 848 [KEYWORDS] S. Bradner, "Key words for use in RFCs to indicate 849 Requirement levels", BCP 14, RFC 2119, March 1997 851 [RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. 852 Jacobson, "RTP: a transport protocol for real-time 853 applications", RFC 1889, Internet Engineering Task 854 Force, January 1996 856 Fairlie-Cuninghame Expires November 2001 16 858 [SCTP] R. Stewart, M. A. Ramalho, Q. Xie, P. Conrad, M. Rose, 859 "Stream Control Transmission Protocol", RFC 2960, 860 October 2000 862 [SCTPAS] L. Coene et al, "Stream Control Transmission Protocol 863 Applicability Statement", Work in progress, IETF draft 865 [SDP] M. Handley, V. Jacobson, "SDP: Session Description 866 Protocol", RFC 2327, April 1998 868 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, 869 "SIP: Session Initiation Protocol", RFC 2543, March 1999 871 [SUA] J. Loughney et al, "SS7 SCCP-User Adaptation Layer", 872 Work in Progress, IETF draft 874 [USCTP] Q. Xie, R. Stewart, C. Sharp, I. Rytina, "SCTP 875 Unreliable Data Mode Extension", Work in Progress, IETF 876 draft 878 [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode 879 and ISO 10646", RFC 2044, October 1996 881 [V5UA] E. Weilandt, F. Ergincan, S. Rao, "V5.2-User Adaption 882 Layer", Work in Progress, IETF draft 884 Author's Address 886 Robert Fairlie-Cuninghame 887 Nuera UK, Ltd. 888 50 Victoria Rd 889 Farnborough 890 Hants GU14 7PG 891 UK 893 Phone: +44-1252-548-200 894 Email: rfairlie@nuera.com 896 Full Copyright Statement 898 Copyright (C) The Internet Society (2001). All Rights Reserved. 900 This document and translations of it may be copied and furnished to 901 others, and derivative works that comment on or otherwise explain it 902 or assist in its implementation may be prepared, copied, published 903 and distributed, in whole or in part, without restriction of any 904 kind, provided that the above copyright notice and this paragraph 905 are included on all such copies and derivative works. However, this 906 document itself may not be modified in any way, such as by removing 907 the copyright notice or references to the Internet Society or other 908 Internet organizations, except as needed for the purpose of 909 developing Internet standards in which case the procedures for 910 copyrights defined in the Internet Standards process must be 912 Fairlie-Cuninghame Expires November 2001 17 913 followed, or as required to translate it into languages other than 914 English. 916 The limited permissions granted above are perpetual and will not be 917 revoked by the Internet Society or its successors or assigns. 919 This document and the information contained herein is provided on an 920 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 921 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 922 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 923 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 924 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 926 Fairlie-Cuninghame Expires November 2001 18