idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-08.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 (November 28, 2014) is 3430 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: 'RFCXXXX' is mentioned on line 543, 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 (~~), 4 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 1, 2015 Ericsson 6 November 28, 2014 8 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 9 Session Description Protocol (SDP) 10 draft-ietf-mmusic-sctp-sdp-08 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' and '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 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 'fmtp' Attribute . . . . . . . . . . . . . . . . . . . . 7 74 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. SCTP Association Management . . . . . . . . . . . . . . . . . 7 77 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.2. SDP setup Attribute . . . . . . . . . . . . . . . . . . . 7 79 7.3. SDP connection Attribute . . . . . . . . . . . . . . . . 8 80 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 8 81 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 9 83 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9 84 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 85 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 86 9. Multihoming Considerations . . . . . . . . . . . . . . . . . 10 87 10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 11 90 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 13.1. New SDP proto values . . . . . . . . . . . . . . . . . . 12 94 13.2. New SDP Attribute . . . . . . . . . . . . . . . . . . . 12 95 13.3. association-usage Name Registry . . . . . . . . . . . . 13 96 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 99 15.2. Informative References . . . . . . . . . . . . . . . . . 15 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 102 1. Introduction 104 SDP (Session Description Protocol) [RFC4566] provides a general- 105 purpose format for describing multimedia sessions in announcements or 106 invitations. TCP-Based Media Transport in the Session Description 107 Protocol (SDP) [RFC4145] specifies a general mechanism for describing 108 and establishing TCP (Transmission Control Protocol) [RFC5246] 109 streams. Connection-Oriented Media Transport over the Transport 110 Layer Security (TLS) Protocol in the Session Description Protocol 111 (SDP) [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based 112 media streams that are protected using TLS. 114 SCTP (Stream Control Transmission Protocol) is a transport protocol 115 used to establish associations between two endpoints. 117 This specification describes how to describe SCTP associations using 118 the Session Description Protocol (SDP) [RFC4566], and defines the 119 following new SDP Media Description [RFC4566] protocol identifiers 120 (proto values):'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'. 122 The specification also describes how to use the new proto values 123 together with the SDP Offer/Answer mechanism [RFC3264] in order to 124 negotiate and establish SCTP associations, and how to indicate the 125 SCTP application usage. 127 NOTE: TLS is designed to run on top of a byte-stream oriented 128 transport protocol providing a reliable, in-sequence delivery like 129 TCP. [RFC6083] presents serious limitations with transporting SCTP 130 on top of TLS. Therefore, defining a mechanism to negotiate media 131 streams transported using SCTP on top of TLS is outside the scope of 132 this specification. 134 2. Terminology 136 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 137 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 138 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 139 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 140 levels for compliant implementations. 142 3. SCTP Terminology 144 SCTP Association: A protocol relationship between SCTP endpoints, 145 composed of the two SCTP endpoints and protocol state information 146 including Verification Tags and the currently active set of 147 Transmission Sequence Numbers (TSNs), etc. An association can be 148 uniquely identified by the transport addresses used by the endpoints 149 in the association. Two SCTP endpoints MUST NOT have more than one 150 SCTP association between them at any given time. 152 SCTP Stream: A unidirectional logical channel established from one to 153 another associated SCTP endpoint, within which all user messages are 154 delivered in sequence except for those submitted to the unordered 155 delivery service. 157 SCTP Transport address: A transport address is traditionally defined 158 by a network-layer address, a transport-layer protocol, and a 159 transport-layer port number. In the case of SCTP running over IP, a 160 transport address is defined by the combination of an IP address and 161 an SCTP port number (where SCTP is the transport protocol). 163 4. SDP Media Descriptions 165 4.1. General 167 This section defines the following new SDP Media Description (m- 168 line) protocol identifiers (proto values) for describing an SCTP 169 association: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'. The section also 170 describes how an m- line, associated with the proto values, is 171 created. 173 The following is the format for an 'm' line, as specified in RFC4566 174 [RFC4566]: 176 m= ... 178 The 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' proto values are similar to 179 both the 'UDP' and 'TCP' proto values in that they only describe the 180 transport protocol and not the upper-layer protocol. 182 NOTE: When the 'DTLS/SCTP' proto value is used, the underlying 183 transport protocol is either UDP or TCP. 185 The m- line fmt value, identifying the application-layer protocol, 186 MUST be registered by IANA. 188 4.2. Protocol Identifiers 190 The new proto values are defined as below: 192 o The 'SCTP' proto value describes an SCTP association, as defined 193 in [RFC4960]. 195 o The 'SCTP/DTLS' proto value describes a Datagram Transport Layer 196 Security (DTLS) [RFC6347] connection on top of an SCTP 197 association, as defined in [RFC6083]. 199 o The 'DTLS/SCTP' proto value describes an SCTP association on top 200 of a DTLS connection, as defined in 201 [I-D.ietf-tsvwg-sctp-dtls-encaps]. 203 NOTE: In the case of 'DTLS/SCTP', the actual transport protocol below 204 DTLS is either UDP or TCP. 206 OPEN ISSUE #1: It is FFS whether separate proto values will be used, 207 depending on whether the underlying transport protocol is UDP (e.g. 208 'UDP/DTLS/SCTP') or TCP (e.g. 'TCP/DTLS/SCTP'). 210 4.3. Media Format Management 212 [RFC4566] defines that specifications defining new proto values must 213 define the rules by which their media format (fmt) namespace is 214 managed. Use of an existing MIME subtype for the format is 215 encouraged. If no MIME subtype exists, it is recommended that a 216 suitable one is registered through the IETF process [RFC6838] 217 [RFC4289] by production of, or reference to, a standards-track RFC 218 that defines the transport protocol for the format. 220 An m- line with a proto value of 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP' 221 always describe a single SCTP association. 223 In addition, such m- line MUST further indicate the application-layer 224 protocol using an 'fmt' identifier. There MUST be exactly one 'fmt' 225 value per m- line associated with the proto values defined in this 226 specification. The "fmt" namespace associated with those proto 227 values describes the generic application usage of the entire SCTP 228 association, including the associated SCTP streams. 230 NOTE: A mechanism on how to describe, and manage, individual SCTP 231 streams within an SCTP association, is outside the scope of this 232 specification. 234 4.4. Syntax 236 sctp-m-line = %x6d "=" 237 ("application" SP sctp-port SP "SCTP" SP sctp-fmt CRLF) / 238 ("application" SP sctp-port SP "SCTP/DTLS" SP sctp-fmt CRLF) / 239 ("application" SP udp-port SP "DTLS/SCTP" SP sctp-fmt CRLF) 241 sctp-port = port 243 udp-port = port 245 sctp-fmt = association-usage 247 association-usage = token 249 4.5. Example 251 m=application 12345 DTLS/SCTP webrtc-datachannel 252 a=fmtp:webrtc-datachannel max-message-size=100000 254 5. SDP 'sctp-port' Attribute 256 5.1. General 258 This section defines a new SDP media-level attribute, 'sctp-port'. 259 The attribute can be associated with an SDP media descriptor (m- 260 line) with a 'DTLS/SCTP' proto value, in which case the m- line port 261 value indicates the port of the underlying transport protocol (UDP or 262 TCP). 264 If the SDP sctp-port attribute is not present, the default value is 265 5000. 267 Usage of the SDP sctp-port attribute with other proto values is not 268 specified, and MUST be discarded if received. 270 5.2. Syntax 272 sctp-port-attr = "a=sctp-port:" portnumber 273 port-number = port 274 port = 1*DIGIT 276 6. SDP 'fmtp' Attribute 278 6.1. General 280 The SDP 'fmtp' attribute can be used with an m- line, associated with 281 an SCTP association, to indicate the maximum message size that an 282 SCTP endpoint is willing to receive, for a particular SCTP 283 association usage, on that SCTP association. 285 The remote peer MUST assume that larger messages will be rejected by 286 the SCTP endpoint. SCTP endpoints need to decide on appropriate 287 behaviour in case a message that exceeds the maximum size needs to be 288 sent. 290 If the SDP 'fmtp' attribute contains a maximum message size value of 291 zero, it indicates the SCTP endpoint will handle messages of any 292 size, subject to memory capacity etc. 294 If the SDP 'fmtp' attribute is not present, the default value is 64K. 296 6.2. Syntax 298 sctpmap-attr = "a=fmtp:" association-usage [max-message-size] 299 max-message-size = "max-message-size" EQUALS 1*DIGIT 301 7. SCTP Association Management 303 7.1. General 305 The management of an SCTP association is identical to the management 306 of a TCP connection. An SCTP endpoints MUST follow the rules in 307 Section 6 of [RFC4145] to manage SCTP associations. Whether to use 308 the SCTP ordered or unordered delivery service is up to the 309 applications using the SCTP association, and this specification does 310 not define a mechanism to indicate the type of delivery service using 311 SDP. 313 7.2. SDP setup Attribute 315 If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', the 316 SDP setup attribute [RFC4145] is used to determine the TLS roles, 317 following the proceduresin [RFC4572] (the 'active' endpoint will take 318 the TLS client role). 320 The SDP setup attribute is not used to determine which endpoint 321 initiates the SCTP association. Instead, both endpoints MUST 322 initiate the SCTP association, and MUST use the same SCTP port as 323 client port and server port (in order to prevent two separate SCTP 324 associations from being established). 326 However, if the proto field value is 'DTLS/SCTP', and the transport 327 layer protocol is TCP (SCTP is carried on top of TCP), the SDP setup 328 attribute is also used to negotiate which endpoint will initiate the 329 TCP connection (send TCP SYN), following the procedures in [RFC4145]. 331 7.3. SDP connection Attribute 333 The SDP connection attribute is used following the procedures in 334 [RFC4145], with the additional SCTP specific considerations described 335 in this section. 337 In general, the SDP connection attribute only applies to an SCTP 338 association. Therefore, if the m- line proto field value is 'DTLS/ 339 SCTP', a connection attribute 'new' value will not automatically re- 340 establish an existing DTLS connection, unless some DTLS properties 341 are also changed in a way which require the DTLS connection to be re- 342 established. 344 However, if the m- line proto field value is 'SCTP/DTLS', if the SCTP 345 association is re-established, the DTLS connection also needs to be 346 re-established. 348 OPEN ISSUE #2: Verify that the above statement regarding 'SCTP/DTLS' 349 is correct. 351 8. SDP Offer/Answer Procedures 353 8.1. General 355 This section defines the SDP Offer/Answer [RFC3264] procedures for 356 negotiating and establishing an SCTP association. Unless explicitly 357 stated, the procedures apply to all protocol identifier values 358 ('SCTP', 'SCTP/DTLS' and 'DTLS/SCTP') defined in this specification. 360 If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', each 361 endpoint MUST provide a certificate fingerprint, using the SDP 362 'fingerprint' attribute [RFC4145], if the endpoint supports, and is 363 willing to use, a cipher suite with an associated certificate. 365 The authentication certificates are interpreted and validated as 366 defined in [RFC4572]. Self-signed certificates can be used securely, 367 provided that the integrity of the SDP description is assured as 368 defined in [RFC4572]. 370 NOTE: The procedures apply to a specific m- line describing an SCTP 371 association. If an offer or answer contains multiple m- line 372 describing SCTP associations, the procedures are applied separately 373 to each m- line. The procedures related to SDP attributes apply to 374 attributes associated with the m- line describing the SCTP 375 association. 377 EDITOR'S NOTE: The offer/answer proceudres for the max-message-size 378 value still need to be added. 380 8.2. Generating the Initial SDP Offer 382 When the offerer creates an offer, if the m- line proto field value 383 is 'SCTP/DTLS' or 'DTLS/SCTP', the offerer MUST insert an SDP setup 384 attribute in the offer, in order to determine the TLS roles, and in 385 cases where SCTP is transported on TCP, determine which endpoint is 386 responsible for establishing the TCP connection [Section 7.2]. 388 The offerer MAY insert an SDP connection attribute, with a 'new' 389 value, in the offer. 391 If the value of the m- line proto field is set to 'DTLS/SCTP', the 392 offerer MAY insert an SDP sctp-port attribute, with a value 393 indicating the local SCTP port, in the offer. 395 8.3. Generating the SDP Answer 397 When the answerer receives an offer, which contains an m- line 398 describing an SCTP association, it MUST insert a corresponding m- 399 line, with an identical m- line proto field value, in the associated 400 answer, following the procedures in [RFC3264]. 402 If the answerer accepts the offered m- line, it assigns the other m- 403 line field values according to Section 4. 405 If the offer contains an SDP setup attribute, the answerer MUST 406 insert a setup attribute in the answer, following the rules in 407 [RFC4572] and [RFC4145] (if applicable). 409 If the value of the m- line proto field is set to 'DTLS/SCTP', the 410 answerer MAY insert an SDP sctp-port attribute, with a value 411 indicating the local SCTP port, in the answer. 413 Once the answerer has sent the answer, if the SCTP association 414 associated with the m- line has yet not been established, or if an 415 existing SCTP association is to be re-established, the answer MUST 416 start establishing the SCTP association towards the peer. 418 If the answerer does not accept the m- line in the offer, it MUST 419 assign a zero value to the port field of the corresponding m- line in 420 the answer. In addition, the answerer MUST NOT insert an SDP setup 421 attribute, or an SDP sctp-port attribute, in the answer. 423 8.4. Offerer Processing of the SDP Answer 425 When the offerer receives an answer, if the SCTP association 426 associated with the m- line has not yet been established, or if an 427 existing SCTP association is to be re-established, the offerer MUST 428 start establishing the SCTP association towards the peer. 430 If the m- line port field value in the answer is zero, the offerer 431 MUST terminate the SCTP association (if it exists) associated with 432 the m- line. 434 8.5. Modifying the Session 436 When an offerer sends an updated offer, in order to modify a 437 previously negotiated SCTP association, it follows the rules in 438 Section 8.2, with the following exceptions: 440 If the offerer wants to re-establish an existing SCTP association 441 associated with the m- line, the offerer MUST insert an SDP 442 connection attribute, with a 'new' value, in the offer. 444 If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', and 445 the offer is not intended to re-establish the DTLS connection, the 446 offerer MUST NOT insert a SDP setup attribute with a value that 447 changes the previously determined TLS roles in the offer. 449 If the offerer wants to disable a previously established SCTP 450 association, it MUST set the port value of the m- line associated 451 with the SCTP association to zero, following the procedures in 452 [RFC3264]. The offerer MUST NOT insert an SDP setup attribute, or an 453 SDP sctp-port attribute, in the offer. 455 NOTE: Different SCTP association applications might define protocol 456 procedures etc that need to be performed before an SCTP association 457 is terminated. Such procedures are outside the scope of this 458 specification. 460 9. Multihoming Considerations 462 SCTP supports multihoming. An SCTP endpoint is considered multihomed 463 if it has more than one IP address on which SCTP can be used. An 464 SCTP endpoint inform the remote peer about its IP addresses using the 465 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP 466 is used to describe an SCTP association, while the "c=" line contains 467 the address which was used to negotiate the SCTP association, 468 multihomed SCTP endpoints might end up using other IP addresses. 470 If an endpoint removes the IP address [RFC5061] that it offered in 471 the SDP "c=" line associated with the SCTP association, it MUST send 472 a new Offer, in which the "c=" line contains an IP address with is 473 valid within the SCTP association. 475 NOTE: In some network environments, intermediaries performing gate- 476 and firewall control use the address information in the SDP "c=" and 477 "m=" lines to authorize media, and will not pass media sent using 478 other addresses. In such network environment, if an SCTP endpoints 479 wants to change the address information on which media is sent and 480 received, it needs to send an updated Offer, in which the SDP "c=" 481 and "m=" lines contain the new address information. 483 Multihoming is not supported when sending SCTP on top of DTLS, as 484 DTLS does not expose address management to its upper layer. 486 10. NAT Considerations 488 10.1. General 490 SCTP features not present in UDP or TCP, including the checksum 491 (CRC32c) value calculated on the whole packet (rather than just the 492 header), and multihoming, introduce new challenges for NAT traversal. 493 [I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT, 494 which provides similar features of Network Address and Port 495 Translation (NAPT). 497 Current NATs typically do not support SCTP. [RFC6951] defines a 498 mechanism for sending SCTP on top of UDP, which makes it possible to 499 use SCTP with NATs and firewalls that do not support SCTP. 501 10.2. ICE Considerations 503 At the time of writing this specification, no procedures have been 504 defined for using ICE ICE (Interactive Connectivity Establishment) 505 [RFC5768] together with SCTP. Such procedures, including the 506 associated SDP Offer/Answer procedures, are outside the scope of this 507 specification, and might be defined in a future specification. 509 11. Examples 511 TODO: ADD EXAMPLES HERE 513 12. Security Considerations 515 [RFC4566] defines general SDP security considerations, while 516 [RFC3264], [RFC4145] and [RFC4572] define security considerations 517 when using the SDP Offer/Answer mechanism to negotiate media streams. 519 [RFC4960] defines general SCTP security considerations. security 520 considerations on SCTP in general, while [RFC6083] defines security 521 considerations when using DTLS on top of SCTP. 523 This specification does not introduce new security considerations in 524 addition to those defined in the specifications listed above. 526 13. IANA Considerations 528 13.1. New SDP proto values 530 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 531 document.] 533 This document updates the "Session Description Protocol (SDP) 534 Parameters" registry, following the procedures in [RFC4566], by 535 adding the following values to the table in the SDP "proto" field 536 registry: 538 +-------+-----------+-----------+ 539 | Type | SDP Name | Reference | 540 +-------+-----------+-----------+ 541 | proto | SCTP | [RFCXXXX] | 542 | proto | SCTP/DTLS | [RFCXXXX] | 543 | proto | DTLS/SCTP | [RFCXXXX] | 544 +-------+-----------+-----------+ 546 Table 1: SDP "proto" field values 548 13.2. New SDP Attribute 550 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 551 document.] 553 This document defines a new SDP media-level attribute,'sctp-port', as 554 follows: 556 Attribute name: sctp-port 557 Type of attribute: media 558 Subject to charset: No 559 Purpose: Indicate the SCTP port value associated 560 with the SDP Media Description. 561 Appropriate values: Integer 562 Contact name: Christer Holmberg 563 Contact e-mail: christer.holmberg@ericsson.com 564 Reference: RFCXXXX 566 13.3. association-usage Name Registry 568 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 569 document.] 571 This specification creates a new IANA registry, following the 572 procedures in [RFC5226], for the "fmt" namespace associated with the 573 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers. Each "fmt" 574 value describes the usage of an entire SCTP association, including 575 all SCTP streams associated with the SCTP association. 577 NOTE: Usage indication of individual SCTP streams is outside the 578 scope of this specification. 580 The "fmt" value, "association-usage", used with these "proto" is 581 required. It is defined in section Section 4. 583 As part of this registry, IANA maintains the following information: 585 association-usage Name: .The identifier of the subprotocol, as will 586 be used in the subfield. 588 association-usage reference: A reference to the document in which 589 the the association usage is defined. 591 association-usage names are to be subject to the "First Come First 592 Served" IANA registration policy [RFC5226]. 594 IANA is asked to add initial values to the registry. 596 | name | Reference | 597 -+--------------------+-------------------------------------+ 598 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx | 599 -+----------------------------------------------------------| 601 Figure 1 603 14. Acknowledgments 605 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 606 Kyzivat, Michael Tuexen for their comments and useful feedback. 608 15. References 610 15.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 616 with Session Description Protocol (SDP)", RFC 3264, June 617 2002. 619 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 620 the Session Description Protocol (SDP)", RFC 4145, 621 September 2005. 623 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 624 Extensions (MIME) Part Four: Registration Procedures", BCP 625 13, RFC 4289, December 2005. 627 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 628 Description Protocol", RFC 4566, July 2006. 630 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 631 Transport Layer Security (TLS) Protocol in the Session 632 Description Protocol (SDP)", RFC 4572, July 2006. 634 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 635 4960, September 2007. 637 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 638 Kozuka, "Stream Control Transmission Protocol (SCTP) 639 Dynamic Address Reconfiguration", RFC 5061, September 640 2007. 642 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 643 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 644 May 2008. 646 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 647 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 649 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 650 Security Version 1.2", RFC 6347, January 2012. 652 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 653 Specifications and Registration Procedures", BCP 13, RFC 654 6838, January 2013. 656 [I-D.ietf-tsvwg-sctp-dtls-encaps] 657 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 658 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 659 dtls-encaps-06 (work in progress), November 2014. 661 15.2. Informative References 663 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 664 Transport Layer Security (DTLS) for Stream Control 665 Transmission Protocol (SCTP)", RFC 6083, January 2011. 667 [RFC5768] Rosenberg, J., "Indicating Support for Interactive 668 Connectivity Establishment (ICE) in the Session Initiation 669 Protocol (SIP)", RFC 5768, April 2010. 671 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 672 Control Transmission Protocol (SCTP) Packets for End-Host 673 to End-Host Communication", RFC 6951, May 2013. 675 [I-D.ietf-behave-sctpnat] 676 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 677 Transmission Protocol (SCTP) Network Address Translation", 678 draft-ietf-behave-sctpnat-09 (work in progress), September 679 2013. 681 Authors' Addresses 683 Christer Holmberg 684 Ericsson 685 Hirsalantie 11 686 Jorvas 02420 687 Finland 689 Email: christer.holmberg@ericsson.com 690 Salvatore Loreto 691 Ericsson 692 Hirsalantie 11 693 Jorvas 02420 694 Finland 696 Email: Salvatore.Loreto@ericsson.com 698 Gonzalo Camarillo 699 Ericsson 700 Hirsalantie 11 701 Jorvas 02420 702 Finland 704 Email: Gonzalo.Camarillo@ericsson.com