One document matched: draft-groves-coap-webrtcdc-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.36 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-groves-coap-webrtcdc-01" category="info">
<front>
<title abbrev="CoAP over WebRTC DC">A WebRTC Data Channel Transport for the Constrained Application Protocol (CoAP)</title>
<author initials="C." surname="Groves" fullname="Christian Groves">
<organization>Huawei</organization>
<address>
<email>Christian.Groves@nteczone.com</email>
</address>
</author>
<author initials="W." surname="Yang" fullname="Weiwei Yang">
<organization>Huawei</organization>
<address>
<email>tommy@huawei.com</email>
</address>
</author>
<date year="2016" month="October" day="17"/>
<area>art</area>
<workgroup>CoRE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The WebRTC framework defines a generic transport service allowing WEB-browsers and other endpoints to exchange generic data from peer to peer utilizing a Stream Control Transmission Protocol (SCTP) transport. This service is known as Web Real Time Communication WebRTC data channels (WebRTC DC). The use of WebRTC DCs for the Constrained Application Protocol (CoAP) allows WebRTC enabled devices to exchange CoAP data between peers in a secure reliable manner.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Whilst the Constrained Application Protocol (CoAP) <xref target="RFC7252"/> was designed for Internet of Things (IoT) deployments in constrained network environments its ready adoption has seen the use of it in a multitude of different network environments. For example <xref target="I-D.silverajan-core-coap-alternative-transports"/> provides use cases for alternate CoAP transports.</t>
<t><xref target="I-D.ietf-core-coap-tcp-tls"/> highlights a number of issues using the native User Datagram Transport (UDP) and envisages deployments more closely integrated with a Web environment. It also proposes the use of the WebSocket protocol <xref target="RFC6455"/>. The use of CoAP over WebRTC DCs has not yet been discussed.</t>
<t>WebRTC is a framework <xref target="I-D.ietf-rtcweb-overview"/> that defines real time protocols for browser-based applications. It allows communications between peer WebRTC endpoints (e.g. browsers) without the need to communicate through a web server.</t>
<t>In addition to protocols for the realtime transport of audio and video, the transport of generic peer-to-peer non-media data has been defined using WebRTC DCs. The non-media data is transported using the Stream Control Transmission Protocol (SCTP) <xref target="RFC4960"/> encapsulated in the Datagram Transport Layer Security (DTLS) <xref target="RFC6347"/>. It allows both reliable and partially reliable transport and provides confidentiality, source authenticated and integrity protected transfers. The use of Interactive Connectivity Establishment (ICE) <xref target="RFC5245"/> allows network address translator (NAT) traversal. The SCTP/DTLS association may be shared with existing audio and video streams enabling multiplexing of several data streams over a single port further facilitating NAT traversal.</t>
<t>Use cases for WebRTC DCs (section 3.1/<xref target="I-D.ietf-rtcweb-data-channel"/> envisage scenarios where the real-time gaming experience is enhanced by additional object state information. Additional scenarios are considered where information such as heart rate sensor or oxygen saturation sensors could augment audio and video in remote medicine scenarios. The transport of such sensor information is what CoAP has been designed for.</t>
<t>This is illustrated in <xref target="fig1"/> showing the WebRTC Trapeziod with added sensor/CoAP information. The left hand side WebRTC endpoint acts as a CoAP to CoAP proxy.</t>
<figure title="CoAP and WebRTC Trapeziod" anchor="fig1"><artwork><![CDATA[
+-----------+ +-----------+
| Web | | Web |
| | Signaling | |
| |-------------| |
| Server | path | Server |
| | | |
+-----------+ +-----------+
/ \
/ \ Application-
/ \ defined over
/ \ HTTP/Websockets
/ Application-defined over \
/ HTTP/Websockets \
/ \
+-----------+ +-----------+
|JS/HTML/CSS| |JS/HTML/CSS|
+-----------+ +-----------+
+-----------+ +-----------+
SensorA | | | |
CoAP/UDP | | | |
+------+ Browser | ------------------------- | Browser +
| | Media path | |
| | (CoAP/WebRTC DC) | |
+-----------+ +-----------+
]]></artwork></figure>
<t>By utilizing the WebRTC DC (SCTP over DTLS over ICE/UDP (or ICE/TCP)) transport for CoAP a number of important features are inherited including: congestion control, order and unordered messages delivery, large message transmission by providing segmentation and reassembly and multiple unidirectional streams. A more detailed analysis of the benefits of WebRTC DCs can be found in section 5/<xref target="I-D.ietf-rtcweb-data-channel"/>. <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/> describes the usage of SCTP over DTLS.</t>
<t>WebRTC defines in-band and out-of-band methods for establishing a data channel and indicating its characteristics. The Data Channel Establishment Protocol (DCEP) <xref target="I-D.ietf-rtcweb-data-protocol"/> provides an in band means of establishing individual data channels. <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> uses the Session Description Protocol (SDP) <xref target="RFC4566"/> to provide an out-of-band means to establish data channels.</t>
<t>By defining the use of CoAP over WebRTC DC it negates the need for the WebRTC endpoint to interwork between any CoAP messages received from local devices to a proprietary WebRTC DC format when signalling a remote WebRTC endpoint.</t>
<t>The SCTP Payload Protocol Identifier (PPID) allows the identification of whether a UTF-8 or Binary encoding is being used and thus facilitates the use of text or binary CoAP protocol serializations.</t>
</section>
<section anchor="reqlang" title="Requirements Language">
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section anchor="structure" title="Constrained Application Protocol">
<t>This section describes the use of CoAP over WebRTC DC as a delta to the information contained in section 2/<xref target="RFC7252"/>.</t>
<t><xref target="fig2"/> shows the CoAP abstract layering as applied to the WebRTC framework.</t>
<figure title="WebRTC protocol layers including CoAP" anchor="fig2"><artwork><![CDATA[
+---------------------------+
| Application |
+------+------+-------------+ \
| DCEP | Requests/Responses | |
| +--------------------| | CoAP
| | Messages | |
+------+--------------------+ /
| SCTP |
+-----------------------------------------+
| STUN | SRTP | DTLS |
+-----------------------------------------+
| ICE |
+-----------------------------------------+
| UDP1 | UDP2 | UDP3 | ... |
+-----------------------------------------+
]]></artwork></figure>
<t>WebRTC DC mandates the use of SCTP over DTLS. Whilst the above diagram indicates the use of ICE over UDP the use of TCP is also possible in fall back scenarios.</t>
<section anchor="message-model" title="Message Model">
<t>WebRTC DC allows application protocol messages to be exchanged by peers. WebRTC supports both a reliable and partially reliable methods of transmitting user messages.</t>
<t>CoAP <xref target="RFC7252"/> supports four message types “Confirmable, Non-Confirmable, Acknowledge and Reset”. As SCTP provides the reliability mechanism the CoAP message types are not needed for CoAP over WebRTC DC.</t>
<t>WebRTC DC does not support multicast usage.</t>
</section>
<section anchor="reqresp" title="Request Response Model">
<t>WebRTC DCs are realized as a pair of one incoming and one outgoing SCTP stream (with the same identifier) allowing bi-directional communication. Each channel has properties (see section 6.4/<xref target="I-D.ietf-rtcweb-data-channel"/> as discussed below:</t>
<t><list style="symbols">
<t>reliable or unreliable message transmission: WebRTC DCs support the per message indication whether user messages are reliable or partially reliable. Partial reliability indicates that message retransmission is limited to a certain number of retransmissions or lifetime. This loosely parallels to the CoAP usage of Confirmable (CON) or Non-confirmable (NON) messages.</t>
<t>in-order or out-of-order message delivery: WebRTC DCs support the per message indication whether user messages are delivered in or out of order. CoAP has been designed for unreliable transports and therefore assumes that messages may arrive out-of-order. CoAP implements a lightweight reliability mechanism to deal with this issue.</t>
<t>priority: WebRTC DCs allows a priority to specified for stream scheduling. The usage of this is application specific. Usage of CoAP has no impact on this parameter. It’s up to the application using CoAP to set this indication.</t>
<t>an optional label: This is an application/implementation specific label. Uniqueness is not guaranteed. Usage of CoAP has no impact on this parameter.</t>
<t>an optional protocol: This is used to indicate the application protocol in use. A value is required to identify the usage of CoAP.</t>
</list></t>
<t>As discussed above WebRTC DC supports an unreliable / un-ordered delivery of messages. Implementations utilizing these data channel characteristics may use CoAP messages and request/response model largely unchanged. In this case the CoAP reliability mechanisms would be used. However as WebRTC DC’s usage of SCTP is reliable or partially reliable there is some redundancy between the functionality that WebRTC DCs and CoAP provides.</t>
<t>The redundancies are identified and discussed in section 2/<xref target="I-D.ietf-core-coap-tcp-tls"/>. Namely:</t>
<t><list style="numbers">
<t>There is no need to carry acknowledgement semantics at a CoAP level.</t>
<t>There is no need for duplicate delivery detection. This is part of the SCTP layer.</t>
</list></t>
</section>
<section anchor="intermediaries-and-caching" title="Intermediaries and Caching">
<t>As CoAP over WebRTC DC is peer to peer no intermediares or caching is expected.</t>
</section>
<section anchor="resource-discovery" title="Resource Discovery">
<t>The usage of CoAP over WebRTC DC has no foreseeable impacts on resource discovery.</t>
</section>
<section anchor="opening-handshake" title="Opening Handshake">
<t>Prior to the establishment of a CoAP over WebRTC DC the characteristics of the SCTP association and data channel may be negotiated by signalling. See <xref target="messagetrans"/> for further details. For example when using SDP <xref target="I-D.ietf-mmusic-sctp-sdp"/> the use of the “SDP max-message-size” attribute indicates the maximum received SCTP message size.</t>
<t>Further characteristics (such as those described in <xref target="reqresp"/>) are negotiated at the establishment of the WebRTC DC.</t>
<t>On establishment of the CoAP over WebRTC DC the client and server MAY send a CoAP Capability and Settings message (CSM see Section 4.3/<xref target="I-D.ietf-core-coap-tcp-tls"/>) as its first message on the connection to establish CoAP specific capabilities. Any capabilities signalled SHALL not contradict previously negotiated chracteristics. Consideration for the individual options are below:</t>
<t><list style="symbols">
<t>Server-Name Setting: CoAP over WebRTC DC clients MAY use the server-name setting option. The initial value is derived based on the signalling method used to establish the WebRTC peer to peer communications. WebRTC does not mandate a signalling method. For example if Websockets is used then the value may be taken from the HTTP host header field.</t>
<t>Max-message size Capability: The CoAP Max-Message-Size shall not exceed the SCTP message size.</t>
<t>Block-wise Transfer Capability: CoAP over WebRTC DC client and server MAY support the use of BERT (Section 5/<xref target="I-D.ietf-core-coap-tcp-tls"/>). See <xref target="messagesize"/> for message size considerations.</t>
<t>Ping and Pong Messages: Ping and Pong messages MAY be sent by CoAP over WebRTC DC clients and servers. However its use as a basic keepalive is not required as WebRTC defines a method to determine liveness (see <xref target="messageendpoint"/>).</t>
<t>Release Messages: CoAP over WebRTC DC clients and servers may support the CoAP Release message. On receipt of a release message the CoAP over WebRTC DC SHALL be closed as per <xref target="messagetrans"/>.</t>
<t>Abort Messages: CoAP over WebRTC DC clients and servers may support the CoAP Abort message. Senders SHALL then close the CoAP over WebRTC DC as per <xref target="messagetrans"/>.</t>
</list></t>
</section>
<section anchor="message-format" title="Message Format">
<t>As discussed in <xref target="I-D.ietf-core-coap-tcp-tls"/> the use of a reliable underlying transport allows the use of a modified CoAP header format. The modified format removes the “Type (T)” and “Message ID” fields and introduces a “length” as illustrated below in <xref target="fig3"/>.</t>
<figure title="CoAP Header with TCP with 8-bit Length in Header" anchor="fig3"><artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Len=13 | TKL | Length (8-bit)| Code | TKL bytes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>CoAP over WebRTC DC implementations shall also use the message format in <xref target="fig3"/> with the following consideration:</t>
<t><list style="symbols">
<t>The length field was added for message delimitation to keep messages separate in TCP. WebRTC DC uses the message orientation of SCTP to preserve message boundaries thus the use of single application message per SCTP user message is mandated by the WebRTC framework. The length field shall be set to 0.</t>
</list></t>
<t>CoAP <xref target="RFC7252"/> supports the use of different content-formats. WebRTC DC defines the use of PPIDs per SCTP user message as follows:</t>
<t><list style="symbols">
<t>WebRTC String: to identify a non-empty JavaScript string encoded in UTF-8.</t>
<t>WebRTC Binary: to identify a non-empty JavaScript binary data (ArrayBuffer, ArrayBufferView or Blob).</t>
</list></t>
<t>Depending on the content-format (see section 12.3/<xref target="RFC7252"/>) an appropriate PPID to the encoding type SHOULD be used to minimise the need for translating between encodings. For example content type of “text/plain” would result in the use of PPID “WebRTC String”.</t>
<t>Author’s note: Specific mappings for each content-format could be provided however given that the formats may change in the future it may be sufficient to offer broad guidance instead.</t>
</section>
<section anchor="option-format-and-value" title="Option Format and Value">
<t>There are no impacts to option formats or values due to the use of CoAP over WebRTC DCs.</t>
<t>Author’s note: Given that the host is determined by the usage of WebRTC are the Uri-Host and Uri-Port relevant? It would seem that this may be valuable to establish a resource tree independent of WebRTC.</t>
</section>
</section>
<section anchor="messagetrans" title="Message Transmission">
<t>In order to use a WebRTC DC, a SCTP over DTLS over ICE/UDP (or ICE/TCP) association must be established. A DTLS connection is established followed by an SCTP association. The out-of-band establishment method through the use of SDP-based Data Channel Negotiation <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/> allows the negotiation of SCTP over DTLS over ICE/UDP as well as the negotiation and establishment of the characteristics of an individual WebRTC DC.</t>
<t>The in-band establishment method through the use of the Data Channel Establishment Protocol (DCEP) <xref target="I-D.ietf-rtcweb-data-protocol"/> only allows for the establishment of a WebRTC DC once the SCTP over DTLS is established. It relies on DATA_CHANNEL_OPEN and DATA_CHANNEL_ACK messages on the relevant SCTP stream to negotiate the properties of the channel. A separate SCTP PPID (50) indicates that the SCTP user message is a WebRTC DCEP message to allow de-multiplexing by the endpoint.</t>
<t>WebRTC DCs are realized as a pair of one incoming and one outgoing SCTP stream (with the same identifier). Requests are sent on an outgoing SCTP stream and received on the peer incoming stream. The SCTP stream identifier is bound to the WebRTC DC instance at the establishment of the data channel. The establishment protocol provides rules for determining the SCTP stream IDs.</t>
<t>WebRTC DC closure (Stream Reset) is supported through the use of the SCTP stream reconfiguration extension defined in <xref target="RFC6525"/>. The SCTP Stream Reconfiguration reset has the effect of setting the numbering sequence of the SCTP stream back to zero. This is separate function to the CoAP “Reset” message. There is no mapping between the SCTP Stream Reset and the CoAP “Reset” message.</t>
<section anchor="messageendpoint" title="Messages and Endpoints">
<t>As per section 2.5/<xref target="I-D.ietf-core-coap-tcp-tls"/> requests can be sent from both the connecting host and the endpoint that accepted the connection. Who initiated the SCTP/DTLS connection has no bearing on the meaning of the CoAP terms client and server.</t>
<t>WebRTC DC mandates the use of DTLS thus the endpoint is identified depending on the security mode.</t>
<t>WebRTC DCs allows the indication of whether a SCTP user message is empty through the use of PPIDs (WebRTC String Empty and WebRTC Binary Empty). CoAP defines the use of empty messages. However from the perspective of SCTP these CoAP messages would still contain header information thus PPIDs for empty data MUST not be used.</t>
<t>CoAP uses an Empty Confirmable message to provoke a Reset message to check the liveness of an endpoint (so called “CoAP” ping). In WebRTC liveness and the ability to send data is determined through the usage of Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness <xref target="RFC7675"/>. Therefore endpoints utilising CoAP over WebRTC DC MUST not use CoAP “reset” messages.</t>
<t>CoAP also uses Empty messages to acknowledge a request. This is not required due to the SCTP level acknowledgement. Therefore Empty messages MUST not be used with CoAP over WebRTC.</t>
</section>
<section anchor="messages-transmitted-reliably" title="Messages Transmitted Reliably">
<t>For CoAP messages marked as confirmable the sender SHALL use a reliable SCTP user message.</t>
<t>A CoAP endpoint MUST use the ordered delivery SCTP service, as described in <xref target="RFC4960"/>, for the CoAP protocol.</t>
<t>CoAP receivers MUST NOT generate CoAP “ACK” or “reset” messages. SCTP level acknowledgement mechanisms are used.</t>
</section>
<section anchor="messages-transmitted-without-reliability" title="Messages Transmitted without Reliability">
<t>WebRTC DC makes use of the SCTP Partial Reliability (SCTP-PR) Extension <xref target="RFC3758"/>. This extension allows a user to indicate on a per message basis how persistent the transport service should be in attempting to send the message to the receiver. One of the benefits of using this extension identified by <xref target="RFC3758"/> is:</t>
<t><list style="numbers">
<t>Some application layer protocols may benefit from being able to use a single SCTP association to carry both reliable content, – such as text pages, billing and accounting information, setup signaling – and unreliable content, e.g., state that is highly sensitive to timeliness, where generating a new packet is more advantageous than transmitting an old one.</t>
</list></t>
<t>This benefit is also one of the reasons the CoAP “Non-Confirmable” message was introduced. However the SCTP-PR and the CoAP “Non-Confirmable” message mechanisms differs in their approach. The SCTP-PR mechanism focuses on sender side behaviour (e.g. when to abandon retransmission). The CoAP “Non-Confirmable” message focuses on receiver side behaviour (e.g. must not send a CoAP ACK). Even with the use of SCTP-PR an SCTP receiver will send an SCTP level ACK for a successfully received SCTP CHUNK. The CoAP “Non-Confirmable” message has no effect on the SCTP level function.</t>
<t>Therefore the use of a CoAP “Non-Confirmable” message type is redundant as the CoAP receiver will never send a CoAP ACK message in response.</t>
<t>SCTP-PR provides a complimentary function and thus CoAP senders who send Non-confirmable messages SHALL also use SCTP-PR for that message.</t>
</section>
<section anchor="message-correlation" title="Message Correlation">
<t>Due to reliability being handled at the SCTP layers the CoAP “Message ID” is not required.</t>
</section>
<section anchor="message-duplication" title="Message Duplication">
<t>The SCTP layer provides message duplication protection. The CoAP application level procedure is not required.</t>
</section>
<section anchor="messagesize" title="Message Size">
<t>The considerations in section 4.1/<xref target="I-D.ietf-core-coap-tcp-tls"/> regarding message size limitations also apply to the use of WebRTC DCs. However <xref target="I-D.ietf-rtcweb-data-channel"/> indicates that senders SHOULD limit the maximum message size to 16KB to avoid monopolization of the SCTP association. Section 5/<xref target=" I-D.ietf-tsvwg-sctp-dtls-encaps"/> provides further details regarding segmentation and reassembly and path maximum transmission unit (MTU) discovery.</t>
<t>Interleaving of large user messages is supported by an SCTP protocol extension defined in <xref target="I-D.ietf-tsvwg-sctp-ndata"/>.</t>
</section>
<section anchor="congestion-control" title="Congestion Control">
<t>SCTP provides congestion control on a per-association basis (see section 5/<xref target="I-D.ietf-rtcweb-data-channel"/>.</t>
</section>
<section anchor="transmission-parameters" title="Transmission Parameters">
<t>The application level parameters defined in section 4.8/<xref target="RFC7252"/> are not relevant to SCTP.</t>
</section>
</section>
<section anchor="requestresponse-semantics" title="Request/Response Semantics">
<t>Request and response semantics for CoAP over WebRTC DC is as per section 5/<xref target="RFC7252"/> with the following exceptions:</t>
<t><list style="symbols">
<t>section 5.2/<xref target="RFC7252"/>: separate responses MUST be used. Given that WebRTC DC provides an SCTP level acknowledgement it is not possible to piggy back CoAP responses.</t>
<t>section 5.3.1/<xref target="RFC7252"/>: due to the use of DTLS the advice regarding token use without using TLS is invalid.</t>
<t>section 5.3.2/<xref target="RFC7252"/>: In addition CoAP request/response matching is unique to a particular WebRTC DC (SCTP StreamID pair).</t>
<t>section 5.8/<xref target="RFC7252"/>: It is not possible to use a 4.05 piggybacked response.</t>
</list></t>
</section>
<section anchor="coap-uri" title="CoAP URI">
<t>CoAP <xref target="RFC7252"/> defines the “coap” and “coaps” URI schemes for identifying CoAP resources and providing a means of locating the resource. <xref target="RFC7252"/> defines these resources for use with CoAP over UDP.</t>
<t>Section 8/<xref target="RFC7252"/> (Multicast CoAP), does not apply to the URI schemes defined in the present specification.</t>
<t>Resources made available via the “coaps+wr” schemes have no shared identity with the other scheme or with the “coap” or “coaps” scheme, even if their resource identifiers indicate the same authority (the same host listening to the same port). The schemes constitute distinct namespaces and, in combination with the authority, are considered to be distinct origin servers.</t>
<section anchor="coapswr-uri-scheme" title="coaps+wr URI scheme">
<figure><artwork><![CDATA[
coaps-wr-URI = "coaps+wr:" "//" host [ ":" port ] path-abempty
[ "?" query ]
]]></artwork></figure>
<t>The semantics defined in section 6.3/<xref target="RFC7252"/>, apply to this URI scheme, with the following changes:</t>
<t><list style="symbols">
<t>The port SHALL be omitted. The underlying UDP or TCP port and SCTP port is negotiated prior to the establishment of the CoAP over WebRTC DC.</t>
</list></t>
</section>
</section>
<section anchor="discovery" title="Discovery">
<section anchor="service-discovery" title="Service Discovery">
<t>WebRTC does not define peer discovery mechanisms. Peers discover each other through the use of the ICE protocol. ICE candidates need to be sent from peer to peer via signalling. The Javascript Session Establishment Protocol (JSEP) <xref target="I-D.ietf-rtcweb-jsep"/> details the generic SDP media descriptions for peer endpoints to determine the characteristics of a session. The actual signalling protocol between application servers is unspecified. WebRTC endpoints MUST implement the network functions detailed by JSEP including ICE functionality.</t>
<t>Whilst the inter-application server signalling protocol is unspecified, the Session Initiation Protocol (SIP) is able to carry SDP for the purposes of establishing a CoAP over WebRTC DC session. SIP allows the use of media feature tags to indicate user agent capabilities <xref target="RFC3840"/>. In order to indicate that a SIP user agent supports the use of CoAP a new “sip.coap” media feature tag is proposed. A CoAP-capable endpoint SHOULD include this media feature tag in its REGISTER requests and OPTION responses. It SHOULD also include the media feature tag in INVITE and UPDATE <xref target="RFC3311"/> requests and responses. Presence of the media feature tag in the contact field of a requestor response can be used to determine that the far end supports CLUE.</t>
<t>The exchange of SDP results in: the underlying transport address (e.g. IPv4 or IPv6), the underlying transport port (e.g. UDP port) the SCTP port and the SCTP StreamID used for the CoAP WebRTC DC being exchanged between the peer endpoints.</t>
</section>
<section anchor="resource-discovery-1" title="Resource Discovery">
<t>On establishment of a CoAP WebRTC DC endpoints are able to use the resource discovery mechanism defined in <xref target="RFC6690"/> for CoAP resources.</t>
</section>
</section>
<section anchor="multicast-coap" title="Multicast CoAP">
<t>WebRTC DCs do not support multicast.</t>
</section>
<section anchor="securing-coap" title="Securing CoAP">
<t>This document defines how to convey CoAP over WebRTC DCs. The WebRTC security architecture <xref target="I-D.ietf-rtcweb-security-arch"/> mandates the use of DTLS for data channels. The use of DTLS 1.2 is compatible with CoAP <xref target="RFC7252"/> which allows makes use of DTLS 1.2.</t>
<t>The use of DTLS for WebRTC is detailed in <xref target="I-D.ietf-rtcweb-security-arch"/>.</t>
</section>
<section anchor="interworking" title="Interworking">
<t>An WebRTC endpoint supporting CoAP may in affect act as a gateway between local sensor devices and a remote peer endpoint. The local sensors may utilise CoAP over an alternate signalling transport such as UDP to the local WebRTC endpoint. The WebRTC endpoint may then utilise CoAP over WebRTC to signal to the remote peer.</t>
<t>A CoAP gateway when converting to and from a WebRTC transport will in general perform the following functions:</t>
<t><list style="symbols">
<t>Map received Empty CoAP message to SCTP level operations and discard the empty message.</t>
<t>Map received ACK message to SCTP level operations and discard the ACK message.</t>
<t>Separate piggy-backed messages.</t>
<t>Provide a mapping between received and sent Tokens in order to match requests and responses.</t>
</list></t>
<t>Other behaviour depends on the type of proxy behaviour the gateway is performing. See section 5.7/<xref target="RFC7252"/> for more details.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security considerations for WebRTC are discussed in <xref target="I-D.ietf-rtcweb-security"/>.</t>
<t>The use of CoAP over WebRTC can potentially negate the risks mentioned in:</t>
<t><list style="symbols">
<t>section 11.3/<xref target="RFC7252"/> on insecure UDP and multicast being used to aid an amplification attack.</t>
<t>section 11.4/<xref target="RFC7252"/> on IP address spoofing and section 11.5/<xref target="RFC7252"/> on Cross-Protocol attacks.</t>
<t>section 11.6/<xref target="RFC7252"/> may also not be relevant as WebRTC endpoints are not expected to be severely constrained.</t>
</list></t>
<t>Of particular relevance to the support of CoAP over WebRTC DC is access to local devices. Devices generating CoAP data are essentially the same as cameras and microphones in that they may expose sensitive data about the user or the location of the device. Thus the guidance of section 4.1/<xref target="I-D.ietf-rtcweb-security"/> applies to devices generating CoAP data. Whilst CoAP has been designed for constrained devices where there is no user interface to inform/request consent, it is assumed that device utilising WebRTC DC for CoAP is more likely at minimum a Class 2 <xref target="RFC7228"/> device that could facilitate consent.</t>
<t>The CoAP media feature tag defined by this document tag may be present in sessions not utilising CoAP, which increases the metadata available about the sending device, which can help an attacker differentiate between multiple devices and help them identify otherwise anonymised users via the fingerprint of features their device supports. To prevent this, SIP signalling SHOULD always be encrypted using TLS <xref target="RFC5630"/>.</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<section anchor="new-webrtc-dc-protocol-value" title="New WebRTC DC Protocol Value">
<t>NOTE: This registration is exactly the same as the registration in <xref target="I-D.savolainen-core-coap-websockets"/>.</t>
<t>This document requests the registration of the subprotocol name “coap.v1” in the WebSocket Subprotocol Name Registry.</t>
<t><list style="symbols">
<t>Subprotocol Identifier: coap.v1</t>
<t>Subprotocol Common Name: Constrained Application Protocol (CoAP)</t>
<t>Subprotocol Definition: This document</t>
</list></t>
</section>
<section anchor="secure-service-name-and-port-number-registration" title="Secure Service Name and Port Number Registration">
<t>No need has been identified to register a new service name and port number for CoAP over WebRTC. Port number allocation is dynamic. The use of the SCTP over DTLS over UDP/TCP results in a layering of services.</t>
</section>
<section anchor="alpn-protocol-id" title="ALPN Protocol ID">
<t><xref target="I-D.ietf-core-coap-tcp-tls"/> defines a new “coap” application protocol negotiation protocol identity. However as the DTLS connection is used to establish a WebRTC application the protocol identifiers defined in <xref target="I-D.ietf-rtcweb-alpn"/> MUST be used. Note: that confidentiality protection does not extend to WebRTC DCs.</t>
</section>
<section anchor="uri-schemes" title="URI Schemes">
<t>This document registers a new URI scheme “coaps+wr” for the use of CoAP over WebRTC DCs. The “coaps+wr” URI schemes can be compared to the “https” URI scheme.</t>
<t>The IANA is requested to add this new URI schemes to the registry established with <xref target="RFC7595"/>.</t>
</section>
<section anchor="new-sip-media-feature-tag" title="New SIP Media Feature Tag">
<t>This specification registers a new media feature tag in the SIP <xref target="RFC3264"/> tree per the procedures defined in <xref target="RFC2506"/> and <xref target="RFC3840"/>.</t>
<t>Media feature tag name: sip.coap</t>
<t>ASN.1 Identifier: 1.3.6.1.8.4.30</t>
<t>Summary of the media feature indicated by this tag: This feature tag indicates that the device supports the Constrained Application Protocol (CoAP).</t>
<t>Values appropriate for use with this feature tag: Boolean.</t>
<t>The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is useful to indicate the support of CoAP.</t>
<t>Related standards or documents: This document</t>
<t>Security Considerations: Security considerations for this media feature tag are discussed in <xref target="Security"/>.</t>
<t>Name(s) and email address(es) of person(s) to contact for further information:</t>
<t><list style="symbols">
<t>CORE workgroup: core@ietf.org</t>
<t>CORE chairs: core-chairs@ietf.org</t>
</list></t>
<t>Intended usage: COMMON</t>
</section>
</section>
<section anchor="examples" title="Examples">
<t>The example SDP Offer shows a CoAP over WebRTC DC utilising out-of-band negotiation <xref target="I-D.ietf-mmusic-data-channel-sdpneg"/>. It is based on the example in section 7.2/<xref target="I-D.ietf-rtcweb-jsep"/>. Modified lines are indicated with “»>” at the start of the line. These indicators are NOT part of the SDP syntax. Note: some lines have been broken into two lines for formatting reasons.</t>
<figure title="Example SDP Offer" anchor="example"><artwork><![CDATA[
v=0
o=- 4962303333179871723 1 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE a1 d1
a=ice-options:trickle
m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=mid:a1
a=msid:57017fee-b6c1-4162-929c-a25110252400
e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=maxptime:120
a=ice-ufrag:ATEn1v9DoTMB9J4r
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=rtcp-mux
a=rtcp-rsize
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7
m=application 0 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=bundle-only
a=mid:d1
a=fmtp:webrtc-datachannel max-message-size=65536
a=sctp-port 5000
a=fingerprint:sha-256
19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04
:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
>>>a=dcmap:0 subprotocol="coap.v1";"label="coap"
]]></artwork></figure>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>We would like to thank the authors of <xref target="I-D.ietf-core-coap-tcp-tls"/> and <xref target="I-D.savolainen-core-coap-websockets"/> for providing a framework for this document. In addition we would like to thank Carsten Bormann for his feedback on message format.</t>
</section>
<section anchor="changelog" title="Changelog">
<t>Changes from version 00:</t>
<t><list style="symbols">
<t>Updated message format to align with draft-core-coap-tcp-tls-04</t>
<t>Updates to align with draft-core-coap-tcp-tls-04 as a result of the merger with websockets. Added section on opening handshake. Added support of CoAP capability messages and BERT.</t>
</list></t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='I-D.ietf-mmusic-data-channel-sdpneg'>
<front>
<title>SDP-based Data Channel Negotiation</title>
<author initials='K' surname='Drage' fullname='Keith Drage'>
<organization />
</author>
<author initials='M' surname='Makaraju' fullname='Maridi Makaraju'>
<organization />
</author>
<author initials='J' surname='Stoetzer-Bradler' fullname='Juergen Stoetzer-Bradler'>
<organization />
</author>
<author initials='R' surname='Ejzak' fullname='Richard Ejzak'>
<organization />
</author>
<author initials='(' surname='(Unknown)' fullname='(Unknown)'>
<organization />
</author>
<date month='September' day='30' year='2016' />
<abstract><t>The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-data-channel-sdpneg-10' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-data-channel-sdpneg-10.txt' />
</reference>
<reference anchor='I-D.ietf-mmusic-sctp-sdp'>
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.</title>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<author initials='R' surname='Shpount' fullname='Roman Shpount'>
<organization />
</author>
<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
<organization />
</author>
<author initials='G' surname='Camarillo' fullname='Gonzalo Camarillo'>
<organization />
</author>
<date month='October' day='7' year='2016' />
<abstract><t>The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sctp-sdp-18' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-18.txt' />
</reference>
<reference anchor='I-D.ietf-rtcweb-alpn'>
<front>
<title>Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
<organization />
</author>
<date month='May' day='5' year='2016' />
<abstract><t>This document specifies two Application Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communications (WebRTC). The "webrtc" label identifies regular WebRTC communications: a DTLS session that is used establish keys for Secure Real-time Transport Protocol (SRTP) or to establish data channels using SCTP over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-alpn-04' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-alpn-04.txt' />
</reference>
<reference anchor='I-D.ietf-rtcweb-data-channel'>
<front>
<title>WebRTC Data Channels</title>
<author initials='R' surname='Jesup' fullname='Randell Jesup'>
<organization />
</author>
<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
<organization />
</author>
<author initials='M' surname='Tuexen' fullname='Michael Tuexen'>
<organization />
</author>
<date month='January' day='4' year='2015' />
<abstract><t>The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-data-channel-13' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-data-channel-13.txt' />
</reference>
<reference anchor='I-D.ietf-rtcweb-data-protocol'>
<front>
<title>WebRTC Data Channel Establishment Protocol</title>
<author initials='R' surname='Jesup' fullname='Randell Jesup'>
<organization />
</author>
<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
<organization />
</author>
<author initials='M' surname='Tuexen' fullname='Michael Tuexen'>
<organization />
</author>
<date month='January' day='4' year='2015' />
<abstract><t>The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for 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.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-data-protocol-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-data-protocol-09.txt' />
</reference>
<reference anchor='I-D.ietf-rtcweb-jsep'>
<front>
<title>Javascript Session Establishment Protocol</title>
<author initials='J' surname='Uberti' fullname='Justin Uberti'>
<organization />
</author>
<author initials='C' surname='Jennings' fullname='Cullen Jennings'>
<organization />
</author>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='September' day='20' year='2016' />
<abstract><t>This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-jsep-16' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-16.txt' />
</reference>
<reference anchor='I-D.ietf-rtcweb-overview'>
<front>
<title>Overview: Real Time Protocols for Browser-based Applications</title>
<author initials='H' surname='Alvestrand' fullname='Harald T. Alvestrand'>
<organization />
</author>
<date month='January' day='21' year='2016' />
<abstract><t>This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-overview-15' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-15.txt' />
</reference>
<reference anchor='I-D.ietf-rtcweb-security'>
<front>
<title>Security Considerations for WebRTC</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='February' day='26' year='2015' />
<abstract><t>The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC". The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-security-08' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-08.txt' />
</reference>
<reference anchor='I-D.ietf-rtcweb-security-arch'>
<front>
<title>WebRTC Security Architecture</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='June' day='8' year='2016' />
<abstract><t>The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC"). This document defines the security architecture for WebRTC.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-rtcweb-security-arch-12' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-12.txt' />
</reference>
<reference anchor='I-D.ietf-tsvwg-sctp-dtls-encaps'>
<front>
<title>DTLS Encapsulation of SCTP Packets</title>
<author initials='M' surname='Tuexen' fullname='Michael Tuexen'>
<organization />
</author>
<author initials='R' surname='Stewart' fullname='Randall Stewart'>
<organization />
</author>
<author initials='R' surname='Jesup' fullname='Randell Jesup'>
<organization />
</author>
<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
<organization />
</author>
<date month='January' day='24' year='2015' />
<abstract><t>The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single homed.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tsvwg-sctp-dtls-encaps-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-dtls-encaps-09.txt' />
</reference>
<reference anchor='I-D.ietf-tsvwg-sctp-ndata'>
<front>
<title>Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol</title>
<author initials='R' surname='Stewart' fullname='Randall Stewart'>
<organization />
</author>
<author initials='M' surname='Tuexen' fullname='Michael Tuexen'>
<organization />
</author>
<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
<organization />
</author>
<author initials='R' surname='Seggelmann' fullname='Robin Seggelmann'>
<organization />
</author>
<date month='July' day='21' year='2016' />
<abstract><t>The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrary large user messages. However, the sender can not interleave different user messages which causes head of line blocking at the sender side. To overcome this limitation, this document adds a new data chunk to SCTP. Whenever an SCTP sender is allowed to send a user data, it can possibly choose from multiple outgoing SCTP streams. Multiple ways for this selection, called stream schedulers, are defined. Some of them don't require the support of user message interleaving, some do.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tsvwg-sctp-ndata-07' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-ndata-07.txt' />
</reference>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC2506' target='http://www.rfc-editor.org/info/rfc2506'>
<front>
<title>Media Feature Tag Registration Procedure</title>
<author initials='K.' surname='Holtman' fullname='K. Holtman'><organization /></author>
<author initials='A.' surname='Mutz' fullname='A. Mutz'><organization /></author>
<author initials='T.' surname='Hardie' fullname='T. Hardie'><organization /></author>
<date year='1999' month='March' />
<abstract><t>This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='31'/>
<seriesInfo name='RFC' value='2506'/>
<seriesInfo name='DOI' value='10.17487/RFC2506'/>
</reference>
<reference anchor='RFC3264' target='http://www.rfc-editor.org/info/rfc3264'>
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<date year='2002' month='June' />
<abstract><t>This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3264'/>
<seriesInfo name='DOI' value='10.17487/RFC3264'/>
</reference>
<reference anchor='RFC3311' target='http://www.rfc-editor.org/info/rfc3311'>
<front>
<title>The Session Initiation Protocol (SIP) UPDATE Method</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<date year='2002' month='October' />
</front>
<seriesInfo name='RFC' value='3311'/>
<seriesInfo name='DOI' value='10.17487/RFC3311'/>
</reference>
<reference anchor='RFC3758' target='http://www.rfc-editor.org/info/rfc3758'>
<front>
<title>Stream Control Transmission Protocol (SCTP) Partial Reliability Extension</title>
<author initials='R.' surname='Stewart' fullname='R. Stewart'><organization /></author>
<author initials='M.' surname='Ramalho' fullname='M. Ramalho'><organization /></author>
<author initials='Q.' surname='Xie' fullname='Q. Xie'><organization /></author>
<author initials='M.' surname='Tuexen' fullname='M. Tuexen'><organization /></author>
<author initials='P.' surname='Conrad' fullname='P. Conrad'><organization /></author>
<date year='2004' month='May' />
<abstract><t>This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3758'/>
<seriesInfo name='DOI' value='10.17487/RFC3758'/>
</reference>
<reference anchor='RFC3840' target='http://www.rfc-editor.org/info/rfc3840'>
<front>
<title>Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='P.' surname='Kyzivat' fullname='P. Kyzivat'><organization /></author>
<date year='2004' month='August' />
<abstract><t>This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3840'/>
<seriesInfo name='DOI' value='10.17487/RFC3840'/>
</reference>
<reference anchor='RFC4566' target='http://www.rfc-editor.org/info/rfc4566'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4566'/>
<seriesInfo name='DOI' value='10.17487/RFC4566'/>
</reference>
<reference anchor='RFC4960' target='http://www.rfc-editor.org/info/rfc4960'>
<front>
<title>Stream Control Transmission Protocol</title>
<author initials='R.' surname='Stewart' fullname='R. Stewart' role='editor'><organization /></author>
<date year='2007' month='September' />
<abstract><t>This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t><t>SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:</t><t>-- acknowledged error-free non-duplicated transfer of user data,</t><t>-- data fragmentation to conform to discovered path MTU size,</t><t>-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</t><t>-- optional bundling of multiple user messages into a single SCTP packet, and</t><t>-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</t><t> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4960'/>
<seriesInfo name='DOI' value='10.17487/RFC4960'/>
</reference>
<reference anchor='RFC5245' target='http://www.rfc-editor.org/info/rfc5245'>
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<date year='2010' month='April' />
<abstract><t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5245'/>
<seriesInfo name='DOI' value='10.17487/RFC5245'/>
</reference>
<reference anchor='RFC5630' target='http://www.rfc-editor.org/info/rfc5630'>
<front>
<title>The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)</title>
<author initials='F.' surname='Audet' fullname='F. Audet'><organization /></author>
<date year='2009' month='October' />
<abstract><t>This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5630'/>
<seriesInfo name='DOI' value='10.17487/RFC5630'/>
</reference>
<reference anchor='RFC6347' target='http://www.rfc-editor.org/info/rfc6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6347'/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/>
</reference>
<reference anchor='RFC6525' target='http://www.rfc-editor.org/info/rfc6525'>
<front>
<title>Stream Control Transmission Protocol (SCTP) Stream Reconfiguration</title>
<author initials='R.' surname='Stewart' fullname='R. Stewart'><organization /></author>
<author initials='M.' surname='Tuexen' fullname='M. Tuexen'><organization /></author>
<author initials='P.' surname='Lei' fullname='P. Lei'><organization /></author>
<date year='2012' month='February' />
<abstract><t>Many applications that use the Stream Control Transmission Protocol (SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6525'/>
<seriesInfo name='DOI' value='10.17487/RFC6525'/>
</reference>
<reference anchor='RFC6690' target='http://www.rfc-editor.org/info/rfc6690'>
<front>
<title>Constrained RESTful Environments (CoRE) Link Format</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<date year='2012' month='August' />
<abstract><t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6690'/>
<seriesInfo name='DOI' value='10.17487/RFC6690'/>
</reference>
<reference anchor='RFC7228' target='http://www.rfc-editor.org/info/rfc7228'>
<front>
<title>Terminology for Constrained-Node Networks</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='M.' surname='Ersue' fullname='M. Ersue'><organization /></author>
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></author>
<date year='2014' month='May' />
<abstract><t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7228'/>
<seriesInfo name='DOI' value='10.17487/RFC7228'/>
</reference>
<reference anchor='RFC7252' target='http://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>
<reference anchor='RFC7595' target='http://www.rfc-editor.org/info/rfc7595'>
<front>
<title>Guidelines and Registration Procedures for URI Schemes</title>
<author initials='D.' surname='Thaler' fullname='D. Thaler' role='editor'><organization /></author>
<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
<author initials='T.' surname='Hardie' fullname='T. Hardie'><organization /></author>
<date year='2015' month='June' />
<abstract><t>This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.</t></abstract>
</front>
<seriesInfo name='BCP' value='35'/>
<seriesInfo name='RFC' value='7595'/>
<seriesInfo name='DOI' value='10.17487/RFC7595'/>
</reference>
<reference anchor='RFC7675' target='http://www.rfc-editor.org/info/rfc7675'>
<front>
<title>Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness</title>
<author initials='M.' surname='Perumal' fullname='M. Perumal'><organization /></author>
<author initials='D.' surname='Wing' fullname='D. Wing'><organization /></author>
<author initials='R.' surname='Ravindranath' fullname='R. Ravindranath'><organization /></author>
<author initials='T.' surname='Reddy' fullname='T. Reddy'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson'><organization /></author>
<date year='2015' month='October' />
<abstract><t>To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.</t><t>This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.</t></abstract>
</front>
<seriesInfo name='RFC' value='7675'/>
<seriesInfo name='DOI' value='10.17487/RFC7675'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor='I-D.ietf-core-coap-tcp-tls'>
<front>
<title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
<organization />
</author>
<author initials='S' surname='Lemay' fullname='Simon Lemay'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
<organization />
</author>
<author initials='B' surname='Silverajan' fullname='Bill Silverajan'>
<organization />
</author>
<author initials='B' surname='Raymor' fullname='Brian Raymor'>
<organization />
</author>
<date month='October' day='11' year='2016' />
<abstract><t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-core-coap-tcp-tls-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-tcp-tls-05.txt' />
<format type='PDF'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-tcp-tls-05.pdf' />
</reference>
<reference anchor='I-D.savolainen-core-coap-websockets'>
<front>
<title>CoAP over WebSockets</title>
<author initials='T' surname='Savolainen' fullname='Teemu Savolainen'>
<organization />
</author>
<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
<organization />
</author>
<author initials='B' surname='Silverajan' fullname='Bill Silverajan'>
<organization />
</author>
<date month='June' day='16' year='2016' />
<abstract><t>This document specifies how to retrieve and update CoAP resources using CoAP requests and responses over the WebSocket Protocol.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-savolainen-core-coap-websockets-07' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-savolainen-core-coap-websockets-07.txt' />
</reference>
<reference anchor='I-D.silverajan-core-coap-alternative-transports'>
<front>
<title>CoAP Communication with Alternative Transports</title>
<author initials='B' surname='Silverajan' fullname='Bill Silverajan'>
<organization />
</author>
<author initials='T' surname='Savolainen' fullname='Teemu Savolainen'>
<organization />
</author>
<date month='December' day='21' year='2015' />
<abstract><t>CoAP has been standardised as an application level REST-based protocol. A single CoAP message is typically encapsulated and transmitted using UDP or DTLS as transports. These transports are optimal solutions for CoAP use in IP-based constrained environments and nodes. However compelling motivation exists for allowing CoAP to operate with other transports and protocols. Examples are M2M communication in cellular networks using SMS, more suitable transport protocols for firewall/NAT traversal, end-to-end reliability and security such as TCP and TLS, or employing proxying and tunneling gateway techniques such as the WebSocket protocol. This draft examines the requirements for conveying CoAP messages to end points over such alternative transports. It also provides a new URI format for representing CoAP resources over alternative transports.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-silverajan-core-coap-alternative-transports-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-silverajan-core-coap-alternative-transports-09.txt' />
</reference>
<reference anchor='RFC6455' target='http://www.rfc-editor.org/info/rfc6455'>
<front>
<title>The WebSocket Protocol</title>
<author initials='I.' surname='Fette' fullname='I. Fette'><organization /></author>
<author initials='A.' surname='Melnikov' fullname='A. Melnikov'><organization /></author>
<date year='2011' month='December' />
<abstract><t>The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6455'/>
<seriesInfo name='DOI' value='10.17487/RFC6455'/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:13:13 |