idnits 2.17.1 draft-ietf-clue-datachannel-06.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 date (January 21, 2015) is 3382 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-19) exists of draft-ietf-clue-protocol-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-protocol (ref. 'I-D.ietf-clue-protocol') == Outdated reference: A later version (-15) exists of draft-ietf-clue-signaling-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-clue-signaling (ref. 'I-D.ietf-clue-signaling') == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-08 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-12 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-sctp-prpolicies-06 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track January 21, 2015 5 Expires: July 25, 2015 7 CLUE Protocol Data Channel 8 draft-ietf-clue-datachannel-06 10 Abstract 12 This document defines how to use the WebRTC Data Channel mechanism in 13 order to realize a data channel, referred to as a CLUE data channel, 14 for transporting CLUE protocol messages between two CLUE entities. 16 The document defines how to describe the SCTPoDTLS association used 17 to realize the CLUE data channel using the Session Description 18 Protocol (SDP), and defines usage of two mechanisms for establishing 19 a CLUE data channel: the Data Channel Establishment Protocol (DCEP) 20 and the SDP-based "SCTP over DTLS" data channel negotiation 21 mechanism. 23 Details and procedures associated with the CLUE protocol, and the SDP 24 Offer/Answer procedures for negotiating usage of a CLUE data channel, 25 are outside the scope of this document. 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 July 25, 2015. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. CLUE Data Channel . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. SDP Considerations . . . . . . . . . . . . . . . . . . . 4 66 3.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2.2. SDP dcpmap Attribute . . . . . . . . . . . . . . . . 5 68 3.2.3. SDP dcsa Attribute . . . . . . . . . . . . . . . . . 6 69 3.2.4. Example . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.3. DCEP Considerations . . . . . . . . . . . . . . . . . . . 6 71 3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3.2. Open CLUE Data Channel . . . . . . . . . . . . . . . 6 73 3.3.3. Close CLUE Data Channel . . . . . . . . . . . . . . . 7 74 3.4. SCTP Considerations . . . . . . . . . . . . . . . . . . . 7 75 3.4.1. SCTP Payload Protocol Identifier (PPID) . . . . . . . 7 76 3.4.2. Reliability . . . . . . . . . . . . . . . . . . . . . 7 77 3.4.3. Order . . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.4.4. Stream Reset . . . . . . . . . . . . . . . . . . . . 8 79 3.4.5. SCTP Multihoming . . . . . . . . . . . . . . . . . . 8 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 5.1. New WebRTC Data Channel Protocol Value . . . . . . . . . 8 83 5.2. New SDP dcmap attribute subprotocol value . . . . . . . . 9 84 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 85 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 8.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 This document defines how to use the WebRTC Data Channel mechanism 94 [I-D.ietf-rtcweb-data-channel] in order to realize a data channel, 95 referred to as a CLUE data channel, for transporting CLUE protocol 96 messages between two CLUE entities. 98 The document defines how to describe the SCTPoDTLS association 99 [I-D.ietf-tsvwg-sctp-dtls-encaps] used to realize the CLUE data 100 channel using the Session Description Protocol (SDP) [RFC4566], and 101 defines usage of two mechanisms for establishing a CLUE data channel: 102 the Data Channel Establishment Protocol (DCEP) 103 [I-D.ietf-rtcweb-data-protocol] and the SDP-based "SCTP over DTLS" 104 data channel negotiation mechanism 105 [I-D.ejzak-mmusic-data-channel-sdpneg]. This includes SCTP 106 considerations specific to a CLUE data channel, the SDP Media 107 Description (m- line) values, usage of SDP attributes and DCEP 108 considerations (when DCEP is used) specific to a CLUE data channel. 110 Details and procedures associated with the CLUE protocol, and the SDP 111 Offer/Answer [RFC3264] procedures for negotiating usage of a CLUE 112 data channel, are outside the scope of this document. 114 Simultaneous usage of DCEP and the SDP-based "SCTP over DTLS" data 115 channel negotiation mechanism for opening a CLUE data channel is 116 outside the scope of this specification. 118 2. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in BCP 14, RFC 2119 123 [RFC2119]. 125 SCTPoDTLS association refers to an SCTP association carried over an 126 DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps]. 128 WebRTC Data Channel refers to a SCTPoDTLS association 129 [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media 130 data between two entities, according to the procedures in 131 [I-D.ietf-rtcweb-data-channel]. 133 CLUE data channel refers to a WebRTC Data Channel 134 [I-D.ietf-rtcweb-data-channel] realization, with a specific set of 135 SCTP characteristics, with the purpose of transporting CLUE protocol 136 [I-D.ietf-clue-protocol] messages between two CLUE entities. 138 CLUE entity refers to a SIP User Agent (UA) [RFC3261] that supports 139 the CLUE data channel and the CLUE protocol. 141 CLUE session refers to a SIP session [RFC3261] between to SIP UAs, 142 where a CLUE data channel, associated with the SIP session, has been 143 established between the SIP UAs. 145 [RFC4960] defines an SCTP stream as a unidirectional logical channel 146 established from one to another associated SCTP endpoint, within 147 which all user messages are delivered in sequence except for those 148 submitted to the unordered delivery service. 150 [RFC4960] defines an SCTP identifier as a unsigned integer, which 151 identifies a SCTP stream. 153 3. CLUE Data Channel 155 3.1. General 157 This section describes the realization of a CLUE Data Channel. This 158 includes a set of SCTP characteristics specific to a CLUE Data 159 Channel, the values of the m- line describing the SCTPoDTLS 160 association associated with the WEBRTC Data Channel, and the usage of 161 either DCEP or SDP-based "SCTP over DTLS" data channel negotiation 162 mechanism for creating the CLUE Data Channel. 164 As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams 165 realizing a WebRTC Data Channel must be associated with the same SCTP 166 association. In addition, both SCTP streams realizing the WebRTC 167 Data Channel must use the same SCTP stream identifier value. These 168 rules also apply to a CLUE Data Channel. 170 Within a given CLUE session, a CLUE entity MUST use a single CLUE 171 Data Channel for transport of all CLUE messages towards its peer. 173 3.2. SDP Considerations 175 3.2.1. General 177 This section defines how to construct the SDP Media Description (m- 178 line) for describing the SCTPoDTLS association used to realize a 179 WebRTC Data Channel. The section also defines how to construct the 180 SDP dcmap attribute, when the SDP-based "SCTP over DTLS" data channel 181 negotiation mechanism is used for establishing a CLUE Data Channel on 182 the SCTPoDTLS association. 184 NOTE: Other protocols than SDP for negotiating usage of a SCTPoDTLS 185 association for realizing a WebRTC Data Channel are outside the scope 186 of this specification. 188 [I-D.ietf-clue-signaling] describes the SDP Offer/Answer procedures 189 for negotiating a CLUE session, including the CLUE controlled media 190 streams and the CLUE Data Channel. 192 3.2.1.1. SDP Media Description Fields 194 As defined in [I-D.ietf-mmusic-sctp-sdp], the field values of an m- 195 line describing an SCTPoDTLS association are set as following: 197 +---------------+--------------+-----------------+------------------+ 198 | media | port | proto | fmt | 199 +---------------+--------------+-----------------+------------------+ 200 | "application" | UDP port | "UDP/DTLS/SCTP" | application | 201 | | value | | usage | 202 | "application" | TCP port | "TCP/DTLS/SCTP" | application | 203 | | value | | usage | 204 +---------------+--------------+-----------------+------------------+ 206 Table 1: SDP "proto" field values 208 As defined in [I-D.ietf-mmusic-sctp-sdp], when the SCTPoDTLS 209 association is used to realize a WebRTC data channel, the value of 210 the application usage part is 'webrtc-datachannel'. 212 3.2.1.2. SDP sctp-port Attribute 214 As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute 215 value is set to the SCTP port of the SCTPoDTLS association. 217 3.2.2. SDP dcpmap Attribute 219 If the the SDP-based "SCTP over DTLS" data channel negotiation 220 mechanism is used to establish a CLUE data channel, the values of the 221 SDP dcmap attribute [I-D.ejzak-mmusic-data-channel-sdpneg], 222 associated with the m- line describing the SCTPoDTLS association used 223 to realize the WebRTC Data Channel, are set as following: 225 +----------+------------+------------+--------+----------+----------+ 226 | stream- | subprotoco | label | ordere | max-retr | max-time | 227 | id | l | | d | | | 228 +----------+------------+------------+--------+----------+----------+ 229 | Value of | "CLUE" | Applicatio | N/A | N/A | N/A | 230 | the SCTP | | n specific | | | | 231 | stream | | | | | | 232 | used to | | | | | | 233 | realize | | | | | | 234 | the CLUE | | | | | | 235 | data | | | | | | 236 | channel | | | | | | 237 +----------+------------+------------+--------+----------+----------+ 239 Table 2: SDP dcmap attribute values 241 3.2.3. SDP dcsa Attribute 243 The SDP dcsa attribute [I-D.ejzak-mmusic-data-channel-sdpneg] is not 244 used when establishing a CLUE data channel. 246 3.2.4. Example 248 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 249 a=sctp-port: 5000 250 a=dcmap:2 subprotocol="CLUE" 252 Figure 1: SDP Media Description for a CLUE Data Channel 254 3.3. DCEP Considerations 256 3.3.1. General 258 This section describes how to realize a CLUE data channel using DCEP. 260 3.3.2. Open CLUE Data Channel 262 Once the SCTPoDTLS association, used to realize a WebRTC Data Channel 263 has been established, the offerer [RFC3264] is responsible for 264 establishing the CLUE data channel. The offerer MUST send a DCEP 265 DATA_CHANNEL_OPEN message [I-D.ietf-rtcweb-data-protocol]. The value 266 of the 'protocol' field MUST be "CLUE". The value of the 'channel 267 type' MUST be 'DATA_CHANNEL_RELIABLE'. 269 Once the offerer has received the associated DCEP DATA_CHANNEL_ACK 270 message [I-D.ietf-rtcweb-data-protocol], the CLUE data channel has 271 been established. 273 If the offerer receives a DCEP DATA_CHANNEL_OPEN message, for the 274 purpose of establishing a CLUE data channel, the offerer MUST reset 275 the SCTP stream, in order to prevent two CLUE data channels from 276 being established within the same CLUE session. The offerer MUST NOT 277 send a DCEP DATA_CHANNEL_ACK message. 279 NOTE: If another mechanism than SDP Offer/Answer is used to negotiate 280 the SCTPoDTLS association used to realize the WebRTC Data Channel, 281 that mechanism needs to describ which endpoint is responsible for 282 sending the DCEP_CHANNEL_OPEN message, etc. 284 3.3.3. Close CLUE Data Channel 286 DCEP [I-D.ietf-rtcweb-data-protocol] does not define a message for 287 closing individual data channels. As described in 288 [I-D.ietf-rtcweb-data-protocol], in order to close a data channel, a 289 SCTP reset message is sent, in order to close the SCTP stream 290 associated with the data channel. The SCTPoDTLS association, and 291 other data channels established on the same association, are not 292 affected by the SCTP reset message. 294 3.4. SCTP Considerations 296 3.4.1. SCTP Payload Protocol Identifier (PPID) 298 As described in [I-D.ietf-rtcweb-data-protocol], the PPID value 50 is 299 used when sending a DCEP message on a SCTPoDTLS association used to 300 realize a WebRTC Data Channel. 302 A CLUE entity MUST use the PPID value 51 when sending a CLUE message 303 on a CLUE data channel. 305 NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value 306 51 indicates that the SCTP message contains data encoded in a UTF-8 307 format. The PPID value 51 does not indicate what application 308 protocol the SCTP message is associated with, only the format in 309 which the data is encoded. 311 +----------+------------+ 312 | Protocol | PPID Value | 313 +----------+------------+ 314 | DCEP | 50 | 315 | CLUE | 51 | 316 +----------+------------+ 318 Table 3: CLUE Data Channel PPID Values 320 3.4.2. Reliability 322 The usage of SCTP for the CLUE Data Channel ensures reliable 323 transport of CLUE protocol [I-D.ietf-clue-protocol] messages. 325 A CLUE entity MUST NOT use the partial reliability and limited 326 retransmission extensions defined in [RFC3758]. 328 NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the 329 partial reliability extension defined in [RFC3758]. This is not 330 needed for a CLUE Data Channel, as messages are required to always be 331 sent reliably. [I-D.ietf-rtcweb-data-channel] also mandates support 332 of the limited retransmission policy defined in 333 [I-D.ietf-tsvwg-sctp-prpolicies]. 335 3.4.3. Order 337 A CLUE entity MUST use the ordered delivery SCTP service, as 338 described in section 6.6 of [RFC4960]. 340 3.4.4. Stream Reset 342 A CLUE entity MUST support the stream reset extension defined in 343 [RFC6525]. 345 The dynamic address reconfiguration extension defined in [RFC5061] 346 MUST be used to signal the support of the stream reset extension 347 defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used. 349 3.4.5. SCTP Multihoming 351 SCTP multi-homing is not supported for SCTPoDTLS associations, and 352 can therefor not be used for a CLUE data channel. 354 4. Security Considerations 356 This specification does not introduce new security considerations, in 357 addition to those defined in [I-D.ietf-rtcweb-data-channel] and 358 [I-D.ietf-rtcweb-data-protocol]. Security considerations associated 359 with the CLUE protocol are defined in [I-D.ietf-clue-protocol]. 361 5. IANA Considerations 363 5.1. New WebRTC Data Channel Protocol Value 365 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 366 document.] 368 This document adds the 'CLUE' value to the "WebSocket Subprotocol 369 Name Registry" as follows: 371 Subprotocl Identifier: CLUE 372 Subprotocol Common Name: CLUE 373 Subprotocol Definition: RFC-XXXX 375 5.2. New SDP dcmap attribute subprotocol value 377 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 378 document.] 380 OPEN ISSUE: [I-D.ejzak-mmusic-data-channel-sdpneg] has not yet 381 created a registry for new subprotocol values. 383 6. Acknowledgments 385 Thanks to Paul Kyzivat and Christian Groves for comments on the 386 document. 388 7. Change Log 390 [RFC EDITOR NOTE: Please remove this section when publishing] 392 Changes from draft-ietf-clue-datachannel-05 394 o "DTLS/SCTP" split into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". 395 o Removed note regarding optionality of including the SDP sctp-port 396 attribute. 397 o Added defintion of 'SCTPoDTLS association' to the Conventions. 398 o Reference to RFC 4566 (SDP) added. 400 Changes from draft-ietf-clue-datachannel-04 402 o Defines DCEP and external SDP negotiation as two separate 403 mechanisms for negotiating a CLUE data channel. 404 o Updates based on technical changes in referenced specifications. 405 o Reference to draft-ietf-mmusic-sctp-sdp added. 407 Changes from draft-ietf-clue-datachannel-03 409 o IANA considerations added. 410 o Editorial changes based on comments from Christian Groves. 412 Changes from draft-ietf-clue-datachannel-02 414 o SDP m- line example fixed. 415 o OPEN ISSUE #1 closed. 416 o - It was agreed (IETF#91) to use draft-ejzak-mmusic-data-channel- 417 sdpneg, as it was adopted as a WG item in MMUSIC. 418 o - Details for draft-ejzak-mmusic-data-channel-sdpneg usage added. 419 o SDP Offer/Answer procedures removed, as they will be defined in 420 the CLUE protocol draft. 421 o References updated. 423 Changes from draft-ietf-clue-datachannel-01 425 o Support of interleaving "MUST"->"SHOULD". 426 o Example updated. 427 o Reference update. 429 Changes from draft-ietf-clue-datachannel-00 431 o SDP Offer/Answer procedures structures according to RFC 3264. 432 o Reference update. 434 Changes from draft-holmberg-clue-datachannel-04 436 o Draft submitted as draft-ietf-clue-data-channel-00. 437 o Editorial nits fixed. 438 o Changes based on comments from Paul Kyzivat (http://www.ietf.org/ 439 mail-archive/web/clue/current/msg03559.html). 440 o - Proto value fixed. 441 o - Explicit text that the partial reliability and limited 442 retransmission policies MUST NOT be used. 443 o - Added open issue on whether the DCEP 'protocol' field value for 444 CLUE should contain a version number. 445 o - Removed paragraph saying that an offerer must not insert more 446 than one m- line describing an SCTPoDTLS association to be used to 447 realize a CLUE Data Channel, as the draft already states that only 448 one CLUE Data Channel per CLUE session shall be opened. 449 o - Added reference to draft-ietf-rtcweb-data-protocol regarding 450 details on reseting SCTP streams. 451 o - Added text saying that the value of the DCEP 'channel type' MUST 452 be DATA_CHANNEL_RELIABLE. 453 o - Clarified that DCEP must be supported, and used in the absence 454 of another mechanism for opening a CLUE Data Channel. 456 Changes from draft-holmberg-clue-datachannel-03 458 o Procedures updated, based on WG agreement (IETF#89) to use DCEP 459 for the CLUE data channel. 460 o Procedures updated, based on WG agreement (IETF#89) that offerer 461 is responsible for sending DCEP DATA_CHANNEL_OPEN. 462 o Editorial changes, and alignments caused by changes in referenced 463 specifications. 465 Changes from draft-holmberg-clue-datachannel-02 467 o PPID value for CLUE messages added 468 o References updated 470 Changes from draft-holmberg-clue-datachannel-01 471 o More text added 473 Changes from draft-holmberg-clue-datachannel-00 475 o Editorial corrections based on comments from Paul K 477 8. References 479 8.1. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 485 A., Peterson, J., Sparks, R., Handley, M., and E. 486 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 487 June 2002. 489 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 490 with Session Description Protocol (SDP)", RFC 3264, June 491 2002. 493 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 494 Description Protocol", RFC 4566, July 2006. 496 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 497 4960, September 2007. 499 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 500 Kozuka, "Stream Control Transmission Protocol (SCTP) 501 Dynamic Address Reconfiguration", RFC 5061, September 502 2007. 504 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 505 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 506 6525, February 2012. 508 [I-D.ietf-clue-protocol] 509 Presta, R. and S. Romano, "CLUE protocol", draft-ietf- 510 clue-protocol-02.txt (work in progress), October 2014. 512 [I-D.ietf-clue-signaling] 513 Kyzivat, P., Xiao, L., Groves, C., and S. Romano, "CLUE 514 Signaling", draft-ietf-clue-signaling-04.txt (work in 515 progress), October 2014. 517 [I-D.ietf-tsvwg-sctp-dtls-encaps] 518 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 519 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 520 dtls-encaps-08.txt (work in progress), January 2015. 522 [I-D.ietf-mmusic-sctp-sdp] 523 Holmberg, C., Loreto, S., and G. Camarillo, "Stream 524 Control Transmission Protocol (SCTP)-Based Media Transport 525 in the Session Description Protocol (SDP)", draft-ietf- 526 mmusic-sctp-sdp-12.txt (work in progress), January 2015. 528 [I-D.ietf-rtcweb-data-channel] 529 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 530 Channels", draft-ietf-rtcweb-data-channel-13.txt (work in 531 progress), January 2015. 533 [I-D.ietf-rtcweb-data-protocol] 534 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 535 Establishment Protocol", draft-ietf-rtcweb-data-protocol- 536 09.txt (work in progress), January 2015. 538 [I-D.ietf-tsvwg-sctp-prpolicies] 539 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 540 "Additional Policies for the Partial Reliability Extension 541 of the Stream Control Transmission Protocol", draft-ietf- 542 tsvwg-sctp-prpolicies-06.txt (work in progress), December 543 2014. 545 [I-D.ejzak-mmusic-data-channel-sdpneg] 546 Drage, K., Makaraju, R., Ejzak, R., and J. Marcon, "SDP- 547 based WebRTC data channel negotiation", draft-ejzak- 548 mmusic-data-channel-sdpneg-02.txt (work in progress), 549 October 2014. 551 8.2. Informative References 553 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 554 Conrad, "Stream Control Transmission Protocol (SCTP) 555 Partial Reliability Extension", RFC 3758, May 2004. 557 Author's Address 558 Christer Holmberg 559 Ericsson 560 Hirsalantie 11 561 Jorvas 02420 562 Finland 564 Email: christer.holmberg@ericsson.com