RTCWeb Working Group                                            R. Jesup
Internet-Draft                                                   Mozilla
Intended status: Standards Track                               S. Loreto
Expires: January 16, April 24, 2014                                         Ericsson
                                                               M. Tuexen
                                        Muenster Univ. of Appl. Sciences
                                                           July 15,
                                                        October 21, 2013

                      WebRTC

                      RTCWeb Data Channel Protocol
                 draft-ietf-rtcweb-data-protocol-00.txt
                 draft-ietf-rtcweb-data-protocol-01.txt

Abstract

   The Web Real-Time Communication (WebRTC) working group is charged to
   provide protocols to support for direct interactive rich
   communication using audio, video, and data between two peers' web-
   browsers.  This document specifies an actual (minor) a simple protocol for how
   the JS-layer DataChannel objects provide the establishing
   symmetric data channels between the peers.  It uses a two way
   handshake and allows sending of user data without waiting for the
   handshake to complete.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 16, April 24, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Opening Handshake  Message Formats . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Control Messages .   4
     5.1.  DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . .   4
     5.2.  DATA_CHANNEL_ACK Message  . . . . .   4
     6.1.  DATA_CHANNEL_OPEN Message . . . . . . . . . . .   6
   6.  Procedures  . . . . .   4
   7.  Procedures . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . .   6
     7.1.  Adding a Channel (in-band open) . . . . . . . . . . . . .   6
     7.2.  Adding a Channel (external negotiation) .   7
   8.  IANA Considerations . . . . . . . .   7
     7.3.  Closing a Channel . . . . . . . . . . . . .   7
     8.1.  SCTP Payload Protocol Identifier  . . . . . . .   7
     7.4.  Sending and Receiving Data . . . . .   7
     8.2.  New Message Type Registry . . . . . . . . . .   8
   8.  Security Considerations . . . . . .   8
     8.3.  New Channel Type Registry . . . . . . . . . . . . .   8
   9.  IANA Considerations . . .   8
     8.4.  New Protocol Registry . . . . . . . . . . . . . . . . . .   8
   10.   9
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   11.
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  10
     10.2.  Informational References . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The DataChannel Protocol data channel protocol is designed to provide, in the WebRTC data
   channel context [I-D.ietf-rtcweb-overview], a generic transport service
   allowing [I-D.ietf-rtcweb-data-channel], a Web Browser simple in-band
   method to exchange generic open symmetric data in a bidirectional
   peer to peer fashion. channels.  As discussed in [I-D.ietf-rtcweb-data-channel]
   [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control
   Transmission Protocol (SCTP) [RFC4960] encapsulated on in the Datagram
   Transport Layer Security (DTLS) [RFC6347] as described in
   [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already
   standardized transport and security features.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   This document uses the following terms:

   Association:  An SCTP association.

   Stream:  A unidirectional stream of an SCTP association.  It is
      uniquely identified by a stream identifier (0-65535). (0-65534).  Note:
      stream identifier 65535 is reserved due to SCTP Init messages
      allowing a maximum of 65535 streams to be negotiated (0-65534).

   Channel:  Two Streams with the same identifier, one in each
      direction, that which are managed together.

4.  Protocol Overview

   This protocol is a simple, low-overhead way to establish
   bidirectional Channels over an SCTP association with a consistent set
   of properties.

   Channels

   The set of consistent properties includes

   o  whether the messages are created by sending transmitted reliable or unreliable.  In
      case of unreliable transmissions, the same level of unreliability
      is used.

   o  whether the messages are delivered in-order or out-of order.

   o  an optional DATA_CHANNEL_OPEN message
   on label for the Channel.

   o  an unused Stream.  There is no handshake, and optional protocol for the Channel.

   o  the outgoing SCTP stream.

   The data channel is
   available protocol uses a two way handshake to send on as soon as the DATA_CHANNEL_OPEN has been sent.
   Alternatively, both sides make externally agree open a data
   channel.  The side wanting to open a set of
   parameters for data channel selects an unused
   Stream and sends a Channel, in which case no DATA_CHANNEL_OPEN message message.  The peer responds with
   a DATA_CHANNEL_ACK message.  Then the data channel is required.

   To avoid glare in open.  Please
   note that the opening Channels, each side must use either even or
   odd Streams when sending a DATA_CHANNEL_OPEN message.  The method
   used can send user messages before the
   DATA_CHANNEL_ACK is received.  These data channel messages are sent
   on the same Stream as the user messages belonging to the data
   channel.  The demultiplexing is based on the SCTP payload protocol
   identifier.

   To avoid glare in opening Channels, each side MUST use either even or
   odd Streams when sending a DATA_CHANNEL_OPEN message.  The method
   used to determine which side uses odd or even is based on the
   underlying DTLS connection role when used in rtcweb, RTCWeb, with the side
   acting as the DTLS client using even stream identifiers.

   Note: There is no attempt to resolve label glare; if both sides open
   a Channel labelled labeled "x" at the same time, there will be two Channels
   labelled
   labeled "x" - one on an even Stream pair, one on an odd pair.

   The protocol field is to ease cross-application interoperation
   ("federation") by identifying the data being passed with an IANA-
   registered string, and may also be useful for homogenous applications
   which may create more than one type of Channel.

   Data that arrives which on an unused Stream MUST be held for a period
   TBD until a DATA_CHANNEL_OPEN arrived for that Channel, or until the
   protocol stack has been told to expect data on that Stream (via
   external negotiation), or until [TBD - report error].  This allows
   for external negotiation of streams (or assumption of negotiation by
   cooperating applications).  If a later DATA_CHANNEL_OPEN arrives that
   conflicts with the pre-set properties of the Channel, an error should
   be signaled to higher levels.

   Channels are closed by an SCTP reset of the Stream.

5.  Opening Handshake

   The opening handshake is based on the multimedia session description
   exchange that happens between the browsers, typically through a Web
   Server acting as the signaling service.

   [I-D.ietf-mmusic-sctp-sdp] defines the  Message Formats

   Every data channel protocol identifier, 'DTLS/
   SCTP', and defines how to establish an SCTP association over DTLS
   using the Session Description Protocol (SDP).

   The SCTP association is created message starts with a one byte field
   called "Message Type" which indicates the number type of streams specified
   by the application, and if not specified, then it SHOULD default to
   16 streams.

   It is recommended that additional streams be available dynamically
   based on [RFC6525].

6.  Control Messages

   Control Messages message.  The
   corresponding values are sent to manage opening bidirectional channels.

   A DATA_CHANNEL_OPEN message is sent on the Stream that is intended to
   be used for a new Channel, and this creates a bidirectional Channel
   that may be used managed by both sides to send data.

6.1. IANA (see Section 8.2).

5.1.  DATA_CHANNEL_OPEN Message

   This message is sent initially on the stream used for user messages
   using the channel.  All DATA_CHANNEL_OPEN messages MUST be sent using
   SCTP options for reliable in-order delivery.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Message Type |  Channel Type |            Priority           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Reliability Parameter                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Label Length          |       Protocol Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               /
     |                             Label                             |
     /                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               /
     |                            Protocol                           |
     /                                                               \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type: 1 byte (unsigned integer)
      This field holds the IANA defined message type for the the
      DATA_CHANNEL_OPEN message.  The suggested value of this field for
      IANA is 0x03.  NOTE: values 0x00-0x02 were used in an older draft
      with incompatible structures.  Any future incompatible message
      changes should define new message types.

   Channel Type: 1 byte (unsigned integer)
      This field specifies the type of the channel to be opened: opened and the
      values are managed by IANA (see Section 8.3):

      DATA_CHANNEL_RELIABLE (0x00):  The channel provides a reliable in-
            order bi-directional communication channel.

      DATA_CHANNEL_RELIABLE_UNORDERED (0x80):  The channel provides a
            reliable unordered bi-directional communication channel.

      DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01):  The channel provides
            a partially-reliable in-order bi-directional Communication
            channel.  User messages will not be retransmitted more times
            than specified in the Reliability Parameter.

      DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81):  The
            channel provides a partial reliable unordered bi-directional
            Communication channel.  User messages will not be
            retransmitted more times than specified in the Reliability
            Parameter.

      DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):  The channel provides
            a partial reliable in-order bi-directional Communication
            channel.  User messages might not be transmitted or
            retransmitted after a specified life-time given in milli-
            seconds in the Reliability Parameter.  This life-time starts
            when providing the user message to the Javascript engine.

      DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82):  The channel
            provides a partial reliable unordered bi-directional
            Communication channel.  User messages might not be
            transmitted or retransmitted after a specified life-time
            given in milli-seconds in the Reliability Parameter.  This
            life-time starts when providing the user message to the
            Javascript engine.

   Priority: 2 bytes (integer)
      The priority of the channel.

   Reliability Parameter: 4 bytes (unsigned integer)
      This field is ignored if a reliable channel is used.
      If a partial reliable channel with limited number of
      retransmissions is used, this field specifies the number of
      retransmissions.  If a partial reliable channel with limited
      lifetime is used, this field specifies the maximum lifetime in
      milliseconds.

   Label Length: 2 bytes (unsigned integer)
      The length of the label field in bytes.

   Protocol Length: 2 bytes (unsigned integer)
      The length of the protocol field in bytes.

   Label: Variable Length (sequence of characters)
      The name of the channel.  This may be an empty string.

   Protocol: Variable Length (sequence of characters)
      The protocol for the channel.  This may be an empty string.  If
      used, it SHOULD be is an IANA-registered protocol.

7.  Procedures

7.1.  Adding a Channel (in-band open)
   When one side wants protocol (see Section 8.4).

5.2.  DATA_CHANNEL_ACK Message

   This message is sent in response to add a channel using in-band declaration, it
   picks an unused outgoing Stream (even DATA_CHANNEL_OPEN_RESPONSE
   message on the stream identifier for DTLS
   clients, or odd used for DTLS servers); if no unused streams are available
   a negotiation to increase user messages using the number is done via [RFC6525], or
   failure is returned.  It should also check that channel.
   Reception of this message tells the other side has opener that the same channel available, and if not then initiate an increase in setup
   handshake is complete.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Message Type |
     +-+-+-+-+-+-+-+-+

   Message Type: 1 byte (unsigned integer)
      This field holds the number of streams.  It then sends a DATA_CHANNEL_OPEN control IANA defined message on the outgoing stream.

   When an DATA_CHANNEL_OPEN is received on an incoming Stream, type for the
   Stream is associated with a newly-created Channel (unless the Stream
   was already part
      DATA_CHANNEL_ACK message.  The suggested value of an externally-negotiated Channel).  If any this field for
      IANA is 0x02.

6.  Procedures

   All data
   had arrived channel protocol messages MUST be sent requesting ordered
   delivery and using reliable transmission.  They MUST be sent on the Stream before
   same outgoing SCTP stream as the Open arrives and had been
   buffered, it is now delivered on user messages belonging to the new Channel.

   The channel_type
   corresponding data channel.  Multiplexing and reliability_parameters fields of demultiplexing is done
   by using the
   DATA_CHANNEL_OPEN SCTP payload protocol identifier (PPID).  Therefore data
   channel protocol message MUST be used to set up the reverse side of sent with the Channel so that both directions use assigned PPID for the same options by default.

7.2.  Adding a Channel (external negotiation)

   When
   data channel protocol (see Section 8.1).  Other message MUST NOT be
   sent using this PPID.

   If one side sides wants to add open a channel using external negotiation, data channel, it
   picks chooses a Stream.  This can be done by asking the protocol to select an
   unused Stream (of the approriate even or odd type), or by simply
   telling free outgoing
   SCTP stream.  If the protocol what Stream to use.  In side is the latter case, DTLS client, it MUST choose an even
   stream identifier, if the
   application side is responsible for avoiding collisions with existing
   Streams.  If the DTLS server, it attempts to re-use a Stream which is part of MUST choose an
   existing Channel,
   odd one.  It fills in the addition should fail.

   In addition to choosing a Stream, parameters of the application should also inform DATA_CHANNEL_OPEN message
   and sends it on the protocol of chosen SCTP stream.

   After the options to use for DATA_CHANNEL_OPEN message has been sent, the sender of it
   can start sending messages.  Note that
   there is no requirement messages containing user data without waiting for both sides to have
   the same options for
   an externally-negotiated stream, though typically this will be reception of the
   case.

   The application must now ensure in an application-specific manner
   that corresponding DATA_CHANNEL_ACK message.
   However, before the DATA_CHANNEL_ACK message or any other side will also inform the protocol that message has
   been received on the selected
   Stream is to be used, data channel, all other messages containing user
   data and belonging to the parameters for sending data from that
   side.

7.3.  Closing a Channel

   Channels channel MUST be closed by and SCTP reset of sent ordered, not
   matter whether the outgoing Stream.  If
   an incoming Stream data channel is reset by ordered or not.  After the
   DATA_CHANNEL_ACK or any other message has been received on the peer, data
   channel, messages containing user data MUST be send ordered on
   ordered data channels and MUST be sent unordered on unordered data
   channels.  Therefore receiving a message containing user data on an
   unused SCTP stream indicates an error.  The corresponding outgoing
   SCTP stream reset SHOULD MUST be issued. reset using [RFC6525].

   If a DATA_CHANNEL_OPEN message is received on an unused stream, the streams in both directions
   stream identifier corresponds to the role of
   a Channel are reset, the Channel is considered fully closed peer and all
   parameters in the
   Streams DATA_CHANNEL_OPEN message are available for reuse for new channel opens.

7.4.  Sending and Receiving Data

   Data shall be valid, then a
   corresponding DATA_CHANNEL_ACK message is sent using PPID's other than on the Data Channel Control
   PPID.  These PPID's should be registered stream with IANA via (TBD).  The
   meaning of these data PPIDs the
   same stream identifier as the one the DATA_CHANNEL_OPEN message was
   received on.

   If a DATA_CHANNEL_OPEN message is received on an already used SCTP
   stream or there are any problems with parameters within the
   DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is
   not well-formed, the receiver MUST reset the corresponding outgoing
   SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK
   message in response to the format received message.  Therefore, receiving an
   SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK
   message has been received indicates to the sender of the
   corresponding DATA_CHANNEL_OPEN message the failure of the data shall be
   specific
   channel setup procedure.

7.  Security Considerations

   This document does not add any additional considerations to the usage of this protocol, ones
   given in [I-D.ietf-rtcweb-security] and typically shall be
   provided
   [I-D.ietf-rtcweb-security-arch].

8.  IANA Considerations

   [NOTE to the higher layers RFC-Editor:

      "RFCXXXX" is to allow proper decoding of be replaced by the data.

   It RFC number you assign this
      document.

   ]

   IANA is RECOMMENDED that higher layers wishing asked to transfer large
   messages fragment them using PPIDs or other mechanisms to avoid
   monopolization update the reference of an already existing SCTP
   PPID assignment and to create three new registries for the data
   channel protocol.

8.1.  SCTP association by Payload Protocol Identifier
   This document uses one already registered SCTP Payload Protocol
   Identifier (PPID).  [RFC4960] creates the transfer registry "SCTP Payload
   Protocol Identifiers" from which this identifier was assigned.  IANA
   is requested to update the reference of a single
   large message, unless a future SCTP draft relaxes this concern.  If
   fragmented solely with assignment to point to
   this document.  Therefore this assignment should be updated to read:

                +----------------+-----------+-----------+
                | Value          | SCTP PPID values, then transmission MUST occur on a
   reliable in-order channel.  If in-band application framing | Reference |
                +----------------+-----------+-----------+
                | WebRTC Control | 50        | [RFCXXXX] |
                +----------------+-----------+-----------+

8.2.  New Message Type Registry

   IANA is used,
   then other options may be possible.

   For WebRTC, data PPID's requested to create a new registration table "Message Type
   Registry" for DOMStrings and binary the data (and
   fragmentation thereof) shall be created.

   All channel protocol to manage the one byte
   "Message Type" field in data sent on a Channel channel messages (see Section 5).

   The assignment of new message types is done through an RFC required
   action, as defined in both directions [RFC5226].  Documentation of the new message
   type MUST be sent over contain the
   underlying Stream using following information:

   1.  A name for the reliability defined when new message type;

   2.  A detailed procedural description of the Channel was
   opened unless use of messages with the options are changed, or per-message options are
   specified by a higher level.

   Data may
       new type within the operation of the data channel protocol.

   Initially the following values need to be sent immediately after sending or receiving a registered:

               +-------------------+-----------+-----------+
               | Name              | Type      | Reference |
               +-------------------+-----------+-----------+
               | Reserved          | 0x00      | [RFCXXXX] |
               | Reserved          | 0x01      | [RFCXXXX] |
               | DATA_CHANNEL_ACK  | 0x02      | [RFCXXXX] |
               | DATA_CHANNEL_OPEN message, or after creating an externally-negotiated
   Channel.

   It | 0x03      | [RFCXXXX] |
               | Unassigned        | 0x04-0xfe |           |
               | Reserved          | 0xff      | [RFCXXXX] |
               +-------------------+-----------+-----------+

8.3.  New Channel Type Registry

   IANA is recommended that requested to create a new registration table "Channel Type
   Registry" for the data channel protocol to manage the one byte
   "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1).

   The assignment of new message size be kept within certain size
   bounds (TBD) types is done through an RFC required
   action, as applications will not be able to defined in [RFC5226].  Documentation of the new channel
   type MUST contain the following information:

   1.  A name for the new channel type;

   2.  A detailed procedural description of the user message handling
       for data channels using this new channel type.

   Please note that if new channel types support arbitrarily-
   large single messages.

8.  Security Considerations

   To ordered and unordered
   message delivery, the high order bit SHOULD be done.

9.  IANA Considerations

   [NOTE used to RFC-Editor:

      "RFCXXXX" indicated
   whether the message delivery is to be replaced by unordered or not.

   Initially the RFC number you assign this
      document.

   ]

   [NOTE to RFC-Editor:

      The suggested following values for the Payload Protocol Identifiers are
      tentative and to be confirmed by IANA.

   ]

   This document defines five new SCTP Payload Protocol Identifiers
   (PPIDs).  [RFC4960] creates the registry "SCTP Payload Protocol
   Identifiers" from which these identifiers need to be assigned.  The
   following values are suggested:

              +---------------------+-----------+-----------+ registered:

   +------------------------------------------------+------+-----------+
   | Value Name                                           | SCTP PPID Type | Reference |
              +---------------------+-----------+-----------+
   +------------------------------------------------+------+-----------+
   | WebRTC Control DATA_CHANNEL_RELIABLE                          | 50 0x00 | [RFCXXXX] |
   | DOMString Last DATA_CHANNEL_RELIABLE_UNORDERED                | 51 0x80 | [RFCXXXX] |
   | Binary Data Partial DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT           | 52 0x01 | [RFCXXXX] |
   | Binary Data Last DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 53 0x81 | [RFCXXXX] |
   | DOMString Partial DATA_CHANNEL_PARTIAL_RELIABLE_TIMED            | 54 0x02 | [RFCXXXX] |
              +---------------------+-----------+-----------+

10.
   | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED  | 0x82 | [RFCXXXX] |
   | Reserved                                       | 0x7f | [RFCXXXX] |
   | Reserved                                       | 0xff | [RFCXXXX] |
   | Unassigned                                     | rest |           |
   +------------------------------------------------+------+-----------+

8.4.  New Protocol Registry

   IANA is requested to create a new registration table "Protocol
   Registry" for the data channel protocol to manage the "Protocol"
   field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1).

   The assignment of new message types is done through an First Come
   First Served action, as defined in [RFC5226].  Documentation of the
   new protocol MUST contain the following information:

   1.  A name for the protocol;

   2.  A reference for the protocol indicated by the registered string.

   Initially this registry is empty.

9.  Acknowledgments
   The authors wish to thank Martin Thompson, Cullen Jennings, Harald
   Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall
   Stewart, Stefan Haekansson and many others for their invaluable
   comments.

11.

10.  References

11.1.

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
              Conrad, "Stream Control Transmission Protocol (SCTP)
              Partial Reliability Extension", RFC 3758, May 2004.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6525]  Stewart, R., Tuexen, M., and P. Lei, "Stream Control
              Transmission Protocol (SCTP) Stream Reconfiguration", RFC
              6525, February 2012.

   [I-D.ietf-mmusic-sctp-sdp]
              Loreto, S. and G. Camarillo, "Stream Control Transmission
              Protocol (SCTP)-Based Media Transport in the Session
              Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04
              (work in progress), June 2013.

   [I-D.ietf-tsvwg-sctp-dtls-encaps]
              Jesup, R., Loreto, S.,
              Tuexen, M., Stewart, R., Jesup, R., and M. Tuexen, S. Loreto, "DTLS
              Encapsulation of SCTP Packets for RTCWEB", draft-ietf-
              tsvwg-sctp-dtls-encaps-00 Packets", draft-ietf-tsvwg-sctp-
              dtls-encaps-02 (work in progress), February October 2013.

11.2.

10.2.  Informational References

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based Applications", draft-ietf-rtcweb-overview-06 (work
              in progress), February 2013.

   [I-D.ietf-rtcweb-data-channel]
              Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data
              Channels", draft-ietf-rtcweb-data-channel-04 draft-ietf-rtcweb-data-channel-05 (work in
              progress), February July 2013.

   [I-D.ietf-rtcweb-security]
              Rescorla, E., "Security Considerations for WebRTC", draft-
              ietf-rtcweb-security-05 (work in progress), July 2013.

   [I-D.ietf-rtcweb-security-arch]
              Rescorla, E., "WebRTC Security Architecture", draft-ietf-
              rtcweb-security-arch-07 (work in progress), July 2013.

Authors' Addresses
   Randell Jesup
   Mozilla
   US

   Email: randell-ietf@jesup.org

   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   FI

   Email: salvatore.loreto@ericsson.com

   Michael Tuexen
   Muenster University of Applied Sciences
   Stegerwaldstrasse 39
   Steinfurt  48565
   DE

   Email: tuexen@fh-muenster.de