idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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). -- The document date (December 19, 2014) is 3406 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) == Missing Reference: 'Section 5' is mentioned on line 503, but not defined == Missing Reference: 'Section 6' is mentioned on line 506, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 656, but not defined == Missing Reference: 'Section 4' is mentioned on line 717, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-06 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC C. Holmberg 3 Internet-Draft S. Loreto 4 Intended status: Standards Track G. Camarillo 5 Expires: June 22, 2015 Ericsson 6 December 19, 2014 8 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 9 Session Description Protocol (SDP) 10 draft-ietf-mmusic-sctp-sdp-11 12 Abstract 14 SCTP (Stream Control Transmission Protocol) is a transport protocol 15 used to establish associations between two endpoints. 17 This specification describes how to describe SCTP associations using 18 the Session Description Protocol (SDP), and defines the following new 19 SDP Media Description protocol identifiers (proto values):'SCTP', 20 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. 22 The specification also describes how to use the new proto values 23 together with the SDP Offer/Answer mechanism in order to negotiate 24 and establish SCTP associations, and how to indicate the SCTP 25 application usage. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 22, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. SCTP Terminology . . . . . . . . . . . . . . . . . . . . . . 4 64 4. SDP Media Descriptions . . . . . . . . . . . . . . . . . . . 4 65 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. Protocol Identifiers . . . . . . . . . . . . . . . . . . 5 67 4.3. Media Format Management . . . . . . . . . . . . . . . . . 5 68 4.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. SDP 'sctp-port' Attribute . . . . . . . . . . . . . . . . . . 6 71 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6. SDP 'max-message-size' Attribute . . . . . . . . . . . . . . 7 74 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. SDP 'fmtp' Attribute . . . . . . . . . . . . . . . . . . . . 7 77 8. UDP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 7 78 9. TCP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 8 79 10. SCTP Association Management . . . . . . . . . . . . . . . . . 8 80 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 8 81 10.2. SDP sendrecv/sendonly/sendrecv/inactive Attribute . . . 8 82 10.3. SDP setup Attribute . . . . . . . . . . . . . . . . . . 8 83 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 8 84 10.3.2. SCTP Association Initiation . . . . . . . . . . . . 9 85 10.3.3. TLS Role Determination . . . . . . . . . . . . . . . 9 86 10.4. SDP connection Attribute . . . . . . . . . . . . . . . . 9 87 11. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 88 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 10 89 11.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 90 11.3. Generating the SDP Answer . . . . . . . . . . . . . . . 11 91 11.4. Offerer Processing of the SDP Answer . . . . . . . . . . 12 92 11.5. Modifying the Session . . . . . . . . . . . . . . . . . 12 93 12. Multihoming Considerations . . . . . . . . . . . . . . . . . 13 94 13. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 13 96 13.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 14 98 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 15. Security Considerations . . . . . . . . . . . . . . . . . . . 14 100 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 101 16.1. New SDP proto values . . . . . . . . . . . . . . . . . . 14 102 16.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 15 103 16.2.1. sctp-port . . . . . . . . . . . . . . . . . . . . . 15 104 16.2.2. max-message-size . . . . . . . . . . . . . . . . . . 15 105 16.3. association-usage Name Registry . . . . . . . . . . . . 16 106 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 107 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 109 19.1. Normative References . . . . . . . . . . . . . . . . . . 17 110 19.2. Informative References . . . . . . . . . . . . . . . . . 19 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 113 1. Introduction 115 SDP (Session Description Protocol) [RFC4566] provides a general- 116 purpose format for describing multimedia sessions in announcements or 117 invitations. TCP-Based Media Transport in the Session Description 118 Protocol (SDP) [RFC4145] specifies a general mechanism for describing 119 and establishing TCP (Transmission Control Protocol) [RFC5246] 120 streams. Connection-Oriented Media Transport over the Transport 121 Layer Security (TLS) Protocol in the Session Description Protocol 122 (SDP) [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based 123 media streams that are protected using TLS. 125 SCTP (Stream Control Transmission Protocol) is a transport protocol 126 used to establish associations between two endpoints. 128 This specification describes how to describe SCTP associations using 129 the Session Description Protocol (SDP) [RFC4566], and defines the 130 following new SDP Media Description [RFC4566] protocol identifiers 131 (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 132 SCTP'. 134 The specification also describes how to use the new proto values 135 together with the SDP Offer/Answer mechanism [RFC3264] in order to 136 negotiate and establish SCTP associations, and how to indicate the 137 SCTP application usage. 139 NOTE: TLS is designed to run on top of a byte-stream oriented 140 transport protocol providing a reliable, in-sequence delivery like 141 TCP. [RFC6083] presents serious limitations with transporting SCTP 142 on top of TLS. Therefore, defining a mechanism to negotiate media 143 streams transported using SCTP on top of TLS is outside the scope of 144 this specification. 146 2. Terminology 148 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 149 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 150 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 151 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 152 levels for compliant implementations. 154 3. SCTP Terminology 156 SCTP Association: A protocol relationship between SCTP endpoints, 157 composed of the two SCTP endpoints and protocol state information 158 including Verification Tags and the currently active set of 159 Transmission Sequence Numbers (TSNs), etc. An association can be 160 uniquely identified by the transport addresses used by the endpoints 161 in the association. Two SCTP endpoints MUST NOT have more than one 162 SCTP association between them at any given time. 164 SCTP Stream: A unidirectional logical channel established from one to 165 another associated SCTP endpoint, within which all user messages are 166 delivered in sequence except for those submitted to the unordered 167 delivery service. 169 SCTP Transport address: A transport address is traditionally defined 170 by a network-layer address, a transport-layer protocol, and a 171 transport-layer port number. In the case of SCTP running over IP, a 172 transport address is defined by the combination of an IP address and 173 an SCTP port number (where SCTP is the transport protocol). 175 4. SDP Media Descriptions 177 4.1. General 179 This section defines the following new SDP Media Description (m- 180 line) protocol identifiers (proto values) for describing an SCTP 181 association: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 182 SCTP'. The section also describes how an m- line, associated with 183 the proto values, is created. 185 The following is the format for an 'm' line, as specified in RFC4566 186 [RFC4566]: 188 m= ... 190 The 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 191 values are similar to both the 'UDP' and 'TCP' proto values in that 192 they only describe the transport-layer protocol and not the upper- 193 layer protocol. 195 NOTE: When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are 196 used, the underlying transport protocol is either UDP or TCP, SCTP is 197 carried on top of either of those transport-layer protocols. 199 The m- line fmt value, identifying the application-layer protocol, 200 MUST be registered by IANA. 202 4.2. Protocol Identifiers 204 The new proto values are defined as below: 206 o The 'SCTP' proto value describes an SCTP association, as defined 207 in [RFC4960]. 209 o The 'SCTP/DTLS' proto value describes a Datagram Transport Layer 210 Security (DTLS) [RFC6347] connection on top of an SCTP 211 association, as defined in [RFC6083]. 213 o The 'UDP/DTLS/SCTP' proto value describes an SCTP association on 214 top of a DTLS connection on top of UDP, as defined in Section 8. 216 o The 'TCP/DTLS/SCTP' proto value describes an SCTP association on 217 top of a DTLS connection on top of TCP, as defined in Section 9. 219 4.3. Media Format Management 221 [RFC4566] defines that specifications defining new proto values must 222 define the rules by which their media format (fmt) namespace is 223 managed. Use of an existing MIME subtype for the format is 224 encouraged. If no MIME subtype exists, it is recommended that a 225 suitable one is registered through the IETF process [RFC6838] 226 [RFC4289] by production of, or reference to, a standards-track RFC 227 that defines the transport protocol for the format. 229 An m- line with a proto value of 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' 230 or 'TCP/DTLS/SCTP' always describe a single SCTP association. 232 In addition, such m- line MUST further indicate the application-layer 233 protocol using an 'fmt' identifier. There MUST be exactly one 'fmt' 234 value per m- line associated with the proto values defined in this 235 specification. The "fmt" namespace associated with those proto 236 values describes the generic application usage of the entire SCTP 237 association, including the associated SCTP streams. 239 NOTE: A mechanism on how to describe, and manage, individual SCTP 240 streams within an SCTP association, is outside the scope of this 241 specification. 243 4.4. Syntax 245 sctp-m-line = %x6d "=" 246 ("application" SP sctp-port SP "SCTP" SP fmt CRLF) / 247 ("application" SP sctp-port SP "SCTP/DTLS" SP fmt CRLF) / 248 ("application" SP udp-port SP "UDP/DTLS/SCTP" SP fmt CRLF) / 249 ("application" SP tcp-port SP "TCP/DTLS/SCTP" SP fmt CRLF) 251 sctp-port = port 253 udp-port = port 255 tcp-port = port 257 fmt = association-usage 259 association-usage = token 261 4.5. Example 263 m=application 12345 UDP/DTLS/SCTP webrtc-datachannel 264 a=max-message-size: 100000 266 5. SDP 'sctp-port' Attribute 268 5.1. General 270 This section defines a new SDP media-level attribute, 'sctp-port'. 271 The attribute can be associated with an SDP media descriptor (m- 272 line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value, in 273 which case the m- line port value indicates the port of the 274 transport-layer protocol (UDP or TCP), on which SCTP is carried. 276 If the SDP sctp-port attribute is not present, the m- line MUST be 277 discarded. 279 Usage of the SDP sctp-port attribute with other proto values is not 280 specified, and MUST be discarded if received. 282 5.2. Syntax 284 sctp-port-attr = "a=sctp-port:" port 285 port = 1*DIGIT 287 6. SDP 'max-message-size' Attribute 289 6.1. General 291 The SDP 'max-message-size' attribute can be associated with an m- 292 line to indicate the maximum message size that an SCTP endpoint is 293 willing to receive on the SCTP association associated with the m- 294 line. 296 The remote peer MUST assume that larger messages will be rejected by 297 the SCTP endpoint. SCTP endpoints need to decide on appropriate 298 behavior in case a message that exceeds the maximum size needs to be 299 sent. 301 If the SDP 'max-message-size' attribute contains a maximum message 302 size value of zero, it indicates the SCTP endpoint will handle 303 messages of any size, subject to memory capacity etc. 305 If the SDP 'max-message-size' attribute is not present, the default 306 value is 64K. 308 NOTE: This specification only defines the usage of the SDP 'max- 309 message-size' attribute when associated with an m- line containing 310 one of the following proto values: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/ 311 SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute with other proto 312 values needs to be defined in a separate specification. 314 6.2. Syntax 316 max-message-size-attr = "a=max-message-size:" max-message-size 317 max-message-size = 1*DIGIT 319 7. SDP 'fmtp' Attribute 321 The SDP 'fmtp' attribute [RFC4566] can be used to carry association- 322 usage specific parameters. If the attribute is used with a specific 323 association-usage, the usage and detailed syntax MUST be defined in 324 that association-usage specification. 326 8. UDP/DTLS/SCTP Transport Realization 328 The UDP/DTLS/SCTP transport is realized as described below: 330 o SCTP on top of DTLS is realized according to the procedures 331 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 333 o DTLS on top of UDP is realized according to the procedures in 334 defined in [RFC6347]. 336 9. TCP/DTLS/SCTP Transport Realization 338 The TCP/DTLS/SCTP transport is realized as described below: 340 o SCTP on top of DTLS is realized according to the procedures 341 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 343 o DTLS on top of TCP is realized using the framing method defined in 344 [RFC4571]. 346 NOTE: DTLS on top of TCP, without using the framing method defined in 347 [RFC4571] is outside the scope of this specification. A separate 348 proto value would need to be registered for such transport 349 realization. 351 10. SCTP Association Management 353 10.1. General 355 The management of an SCTP association is identical to the management 356 of a TCP connection. An SCTP endpoints MUST follow the rules in 357 Section 6 of [RFC4145] to manage SCTP associations. Whether to use 358 the SCTP ordered or unordered delivery service is up to the 359 applications using the SCTP association, and this specification does 360 not define a mechanism to indicate the type of delivery service using 361 SDP. 363 10.2. SDP sendrecv/sendonly/sendrecv/inactive Attribute 365 This specification does not define semantics for the SDP direction 366 attributes [RFC4566]. Specifications for an individual SCTP 367 association usage MAY define how the attributes can be used with that 368 usage. Unless semantics of these attributes for an SCTP association 369 usage have been defined, SDP direction attributes MUST be discarded 370 if present. 372 10.3. SDP setup Attribute 374 10.3.1. General 376 The SDP setup attribute is used to determine the 'active/passive' 377 status of the endpoints, following the procedures for TCP in 378 [RFC4145]. 380 10.3.2. SCTP Association Initiation 382 Both the 'active' and 'passive' endpoint MUST initiate the SCTP 383 association, and MUST use the same SCTP port as client port and 384 server port (in order to prevent two separate SCTP associations from 385 being established). 387 NOTE: The procedure above is different from TCP, where only the 388 'active' endpoint initiates the TCP connection [RFC4145]. 390 If the m- line proto value is 'TCP/DTLS/SCTP', only the 'active' 391 endpoint will initiate the TCP connection, following the procedures 392 in [RFC4145]. Both endpoints will still initiate the SCTP 393 association on top of the TCP connection. 395 10.3.3. TLS Role Determination 397 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 398 'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the 399 TLS roles of the endpoints. Following the procedures in [RFC4572], 400 the 'active' endpoint will take the TLS client role. 402 Once a DTLS connection has been established, if the 'active/passive' 403 status of the endpoints change (as result of an offer/answer 404 transaction) during a session, a new DTLS connection MUST be 405 established. Therefore, endpoints SHOULD NOT change the 'active/ 406 passive' status during a session, unless they want to establish a new 407 DTLS connection. 409 If the transport parameters or the key fingerprints change, the 410 endpoints MUST establish a new DTLS connection. In such case the 411 'active/passive' status of the endpoints will again be determined 412 following the procedures in [RFC4145], and the new status will be 413 used to determine the TLS roles of the endpoints associated with the 414 new DTLS connection. 416 NOTE: The procedure above is identical to the one defined for SRTP- 417 DTLS in [RFC5763]. 419 10.4. SDP connection Attribute 421 The SDP connection attribute is used following the procedures in 422 [RFC4145], with the additional SCTP specific considerations described 423 in this section. 425 If the m- line proto value is 'TCP/DTLS/SCTP', an SDP connection 426 attribute associated with that m- line applies to both the SCTP 427 association and the TCP connection. Therefore, an attribute 'new' 428 value indicates that both a new SCTP association, and a new TCP 429 connection, have to be established, following the procedures in 430 [RFC4145]. 432 NOTE: This specification does not define a mechanism which allows re- 433 establishing of a new SCTP association, while maintaining the TCP 434 connection. 436 The SDP connection attribute value does not automatically impact an 437 existing DTLS connection. Section 10.3.3 describes in which cases a 438 new DTLS connections will be established. 440 NOTE: If the m- line proto value is 'SCTP/DTLS', and if the SCTP 441 association is re-established, the DTLS connection also needs to be 442 re-established. 444 11. SDP Offer/Answer Procedures 446 11.1. General 448 This section defines the SDP Offer/Answer [RFC3264] procedures for 449 negotiating and establishing an SCTP association. Unless explicitly 450 stated, the procedures apply to all m- line proto values ('SCTP', 451 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP') defined in this 452 specification. 454 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 455 'TCP/DTLS/SCTP', each endpoint MUST provide a certificate 456 fingerprint, using the SDP 'fingerprint' attribute [RFC4145], if the 457 endpoint supports, and is willing to use, a cipher suite with an 458 associated certificate. 460 The authentication certificates are interpreted and validated as 461 defined in [RFC4572]. Self-signed certificates can be used securely, 462 provided that the integrity of the SDP description is assured as 463 defined in [RFC4572]. 465 NOTE: The procedures apply to a specific m- line describing an SCTP 466 association. If an offer or answer contains multiple m- lines 467 describing SCTP associations, the procedures are applied separately 468 to each m- line. 470 11.2. Generating the Initial SDP Offer 472 When the offerer creates an initial offer, the offerer: 474 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 475 or 'TCP/DTLS/SCTP', associate an SDP setup attribute 476 [Section 10.3], with an 'actpass' value, with the m- line; 478 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 479 associate an SDP 'sctp-port' attribute [Section 5] with the m- 480 line; 482 o MUST associate an SDP 'connection' attribute [Section 10.4], with 483 a 'new' value, with the m- line; and 485 o MAY associate an SDP 'max-message-size' attribute [Section 6] with 486 the m- line. 488 11.3. Generating the SDP Answer 490 When the answerer receives an offer, which contains an m- line 491 describing an SCTP association, if the answerer accepts the m- line 492 it: 494 o MUST insert a corresponding m- line in the answer, with an 495 identical m- line proto value [RFC3264]; 497 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 498 or 'TCP/DTLS/SCTP', associate an SDP 'setup' attribute 499 [Section 10.3], with an 'active' or 'passive' value, with the m- 500 line; 502 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 503 associate an SDP 'sctp-port' attribute[Section 5] with the m- 504 line; and 506 o MAY associate an SDP 'max-message-size' attribute [Section 6] with 507 the m- line. 509 Once the answerer has sent the answer, the answerer: 511 o MUST, if an SCTP association associated with the m- line has yet 512 not been established, or if an existing SCTP association is to be 513 re-established, initiate the establishing of the SCTP association; 514 and 516 o MUST, if the answerer is the 'active' endpoint, and if an DTLS 517 connection associated with the m- line is to be established (or 518 re-established), initiate the establishing of the DTLS connection 519 (by sending a ClientHello message). 521 If the answerer does not accept the m- line in the offer, it MUST 522 assign a zero port value to the corresponding m- line in the answer. 523 In addition, the answerer MUST NOT establish an SCTP association, or 524 a DTLS connection, associated with the m- line. 526 11.4. Offerer Processing of the SDP Answer 528 When the offerer receives an answer, which contains an m- line with a 529 non-zero port value, describing an SCTP association, the offerer: 531 o MUST, if the offerer is the 'active' endpoint, if the m- line 532 proto is 'TCP/DTLS/SCTP', and if a TCP connection used to carry 533 the SCTP association has yet not been established (or if an 534 existing TCP connection is to be re-established), initiate the 535 establishing of the TCP connection; 537 o MUST, if an SCTP association associated with the m- line has yet 538 not been established (or if an existing SCTP association is to be 539 re-established), initiate the establishing of the SCTP 540 association; and 542 o MUST, if the offerer is the 'active' endpoint, and if an DTLS 543 connection associated with the m- line is to be established (or if 544 an existing DTLS connection is to be re-established), initiate the 545 establishing of the DTLS connection (by sending a ClientHello 546 message). 548 If the m- line in the answer contains a zero port value, the offerer 549 MUST NOT establish a TCP connection, an SCTP association, or a DTLS 550 connection, associated with the m- line. 552 11.5. Modifying the Session 554 When an offerer sends an updated offer, in order to modify a 555 previously established SCTP association, it follows the procedures in 556 Section 11.2, with the following exceptions: 558 o Unless the offerer wants to re-establish an existing SCTP 559 association, the offerer MUST associate an SDP connection 560 attribute, with an 'existing' value, with the m- line; and 562 o If the offerer wants to disable a previously established SCTP 563 association, it MUST assign a zero port value to the m- line 564 associated with the SCTP association, following the procedures in 565 [RFC3264]. 567 NOTE: Different SCTP association usages might define protocol 568 procedures etc that need to be performed before an SCTP association 569 is terminated. Such procedures are outside the scope of this 570 specification. 572 12. Multihoming Considerations 574 SCTP supports multihoming. An SCTP endpoint is considered multihomed 575 if it has more than one IP address on which SCTP can be used. An 576 SCTP endpoint inform the remote peer about its IP addresses using the 577 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP 578 is used to describe an SCTP association, while the "c=" line contains 579 the address which was used to negotiate the SCTP association, 580 multihomed SCTP endpoints might end up using other IP addresses. 582 If an endpoint removes the IP address [RFC5061] that it offered in 583 the SDP "c=" line associated with the SCTP association, it MUST send 584 a new Offer, in which the "c=" line contains an IP address with is 585 valid within the SCTP association. 587 NOTE: In some network environments, intermediaries performing gate- 588 and firewall control use the address information in the SDP "c=" and 589 "m=" lines to authorize media, and will not pass media sent using 590 other addresses. In such network environment, if an SCTP endpoints 591 wants to change the address information on which media is sent and 592 received, it needs to send an updated Offer, in which the SDP "c=" 593 and "m=" lines contain the new address information. 595 Multihoming is not supported when sending SCTP on top of DTLS, as 596 DTLS does not expose address management to its upper layer. 598 13. NAT Considerations 600 13.1. General 602 SCTP features not present in UDP or TCP, including the checksum 603 (CRC32c) value calculated on the whole packet (rather than just the 604 header), and multihoming, introduce new challenges for NAT traversal. 605 [I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT, 606 which provides similar features of Network Address and Port 607 Translation (NAPT). 609 Current NATs typically do not support SCTP. [RFC6951] defines a 610 mechanism for sending SCTP on top of UDP, which makes it possible to 611 use SCTP with NATs and firewalls that do not support SCTP. 613 13.2. ICE Considerations 615 At the time of writing this specification, no procedures have been 616 defined for using ICE (Interactive Connectivity Establishment) 617 [RFC5768] together with SCTP. Such procedures, including the 618 associated SDP Offer/Answer procedures, are outside the scope of this 619 specification, and might be defined in a future specification. 621 14. Examples 623 TODO: ADD EXAMPLES HERE 625 15. Security Considerations 627 [RFC4566] defines general SDP security considerations, while 628 [RFC3264], [RFC4145] and [RFC4572] define security considerations 629 when using the SDP offer/answer mechanism to negotiate media streams. 631 [RFC4960] defines general SCTP security considerations. security 632 considerations on SCTP in general, while [RFC6083] defines security 633 considerations when using DTLS on top of SCTP. 635 This specification does not introduce new security considerations in 636 addition to those defined in the specifications listed above. 638 16. IANA Considerations 640 16.1. New SDP proto values 642 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 643 document.] 645 This document updates the "Session Description Protocol (SDP) 646 Parameters" registry, following the procedures in [RFC4566], by 647 adding the following values to the table in the SDP "proto" field 648 registry: 650 +-------+---------------+-----------+ 651 | Type | SDP Name | Reference | 652 +-------+---------------+-----------+ 653 | proto | SCTP | [RFCXXXX] | 654 | proto | SCTP/DTLS | [RFCXXXX] | 655 | proto | UDP/DTLS/SCTP | [RFCXXXX] | 656 | proto | TCP/DTLS/SCTP | [RFCXXXX] | 657 +-------+---------------+-----------+ 659 Table 1: SDP "proto" field values 661 16.2. New SDP Attributes 663 16.2.1. sctp-port 665 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 666 document.] 668 This document defines a new SDP media-level attribute,'sctp-port', as 669 follows: 671 Attribute name: sctp-port 672 Type of attribute: media 673 Subject to charset: No 674 Purpose: Indicate the SCTP port value associated 675 with the SDP Media Description. 676 Appropriate values: Integer 677 Contact name: Christer Holmberg 678 Contact e-mail: christer.holmberg@ericsson.com 679 Reference: RFCXXXX 681 16.2.2. max-message-size 683 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 684 document.] 686 This document defines a new SDP media-level attribute,'max-message- 687 size', as follows: 689 Attribute name: max-message-size 690 Type of attribute: media 691 Subject to charset: No 692 Purpose: Indicate the maximum message size that 693 an SCTP endpoint is willing to receive 694 on the SCTP association associated 695 with the SDP Media Description. 696 Appropriate values: Integer 697 Contact name: Christer Holmberg 698 Contact e-mail: christer.holmberg@ericsson.com 699 Reference: RFCXXXX 701 16.3. association-usage Name Registry 703 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 704 document.] 706 This specification creates a new IANA registry, following the 707 procedures in [RFC5226], for the "fmt" namespace associated with the 708 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol 709 identifiers. Each "fmt" value describes the usage of an entire SCTP 710 association, including all SCTP streams associated with the SCTP 711 association. 713 NOTE: Usage indication of individual SCTP streams is outside the 714 scope of this specification. 716 The "fmt" value, "association-usage", used with these "proto" is 717 required. It is defined in [Section 4]. 719 As part of this registry, IANA maintains the following information: 721 association-usage name: .The identifier of the subprotocol, as will 722 be used as the "fmt" value. 724 association-usage reference: A reference to the document in which 725 the association-usage is defined. 727 association-usage names are to be subject to the "First Come First 728 Served" IANA registration policy [RFC5226]. 730 IANA is asked to add initial values to the registry. 732 | name | Reference | 733 -+--------------------+-------------------------------------+ 734 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx | 735 -+----------------------------------------------------------| 737 Figure 1 739 17. Acknowledgments 741 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 742 Kyzivat, Michael Tuexen for their comments and useful feedback. 744 18. Change Log 746 [RFC EDITOR NOTE: Please remove this section when publishing] 748 Changes from draft-ietf-mmusic-sctp-sdp-10 750 o SDP max-message-size attribute added to IANA considerations. 752 o Changes based on comments from Paul Kyzivat: 754 o - Text about max message size removed from fmtp attribute section. 756 Changes from draft-ietf-mmusic-sctp-sdp-09 758 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 760 o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP 761 transports added. 763 Changes from draft-ietf-mmusic-sctp-sdp-08 765 o Default SCTP port removed: 767 o - Usage of SDP sctp-port attribute mandatory. 769 o SDP max-message-size attribute defined: 771 o - Attribute definition. 773 o - SDP Offer/Answer procedures. 775 o Text about SDP direction attributes added. 777 o Text about TLS role determination added. 779 19. References 781 19.1. Normative References 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, March 1997. 786 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 787 with Session Description Protocol (SDP)", RFC 3264, June 788 2002. 790 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 791 the Session Description Protocol (SDP)", RFC 4145, 792 September 2005. 794 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 795 Extensions (MIME) Part Four: Registration Procedures", BCP 796 13, RFC 4289, December 2005. 798 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 799 Description Protocol", RFC 4566, July 2006. 801 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 802 and RTP Control Protocol (RTCP) Packets over Connection- 803 Oriented Transport", RFC 4571, July 2006. 805 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 806 Transport Layer Security (TLS) Protocol in the Session 807 Description Protocol (SDP)", RFC 4572, July 2006. 809 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 810 4960, September 2007. 812 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 813 Kozuka, "Stream Control Transmission Protocol (SCTP) 814 Dynamic Address Reconfiguration", RFC 5061, September 815 2007. 817 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 818 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 819 May 2008. 821 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 822 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 824 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 825 Security Version 1.2", RFC 6347, January 2012. 827 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 828 Specifications and Registration Procedures", BCP 13, RFC 829 6838, January 2013. 831 [I-D.ietf-tsvwg-sctp-dtls-encaps] 832 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 833 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 834 dtls-encaps-06 (work in progress), November 2014. 836 19.2. Informative References 838 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 839 for Establishing a Secure Real-time Transport Protocol 840 (SRTP) Security Context Using Datagram Transport Layer 841 Security (DTLS)", RFC 5763, May 2010. 843 [RFC5768] Rosenberg, J., "Indicating Support for Interactive 844 Connectivity Establishment (ICE) in the Session Initiation 845 Protocol (SIP)", RFC 5768, April 2010. 847 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 848 Transport Layer Security (DTLS) for Stream Control 849 Transmission Protocol (SCTP)", RFC 6083, January 2011. 851 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 852 Control Transmission Protocol (SCTP) Packets for End-Host 853 to End-Host Communication", RFC 6951, May 2013. 855 [I-D.ietf-behave-sctpnat] 856 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 857 Transmission Protocol (SCTP) Network Address Translation", 858 draft-ietf-behave-sctpnat-09 (work in progress), September 859 2013. 861 Authors' Addresses 863 Christer Holmberg 864 Ericsson 865 Hirsalantie 11 866 Jorvas 02420 867 Finland 869 Email: christer.holmberg@ericsson.com 871 Salvatore Loreto 872 Ericsson 873 Hirsalantie 11 874 Jorvas 02420 875 Finland 877 Email: Salvatore.Loreto@ericsson.com 878 Gonzalo Camarillo 879 Ericsson 880 Hirsalantie 11 881 Jorvas 02420 882 Finland 884 Email: Gonzalo.Camarillo@ericsson.com