One document matched: draft-cbran-rtcweb-protocols-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-cbran-rtcweb-protocols-00"
ipr="noDerivativesTrust200902">
<front>
<title abbrev="Abbreviated-Title">RTC-Web Communications Protocols</title>
<author fullname="Cary Bran" initials="C." surname="Bran">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 206 256-3502</phone>
<email>cbran@cisco.com</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<date day="5" month="June" year="2011" />
<abstract>
<t>The real time communications web (RTC-Web) will enable applications
such as web browsers to natively support real time interactive voice and
video. This document outlines the communication protocols for realizing
RTC-Web functionality within applications such as web browsers. In
addition to communications protocols, this document proposes a set of
application programming interface requirements for controlling the
protocol stack.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Internet was, from very early in its lifetime, considered a
possible vehicle for the deployment of real-time, interactive
applications - with the most easily imaginable being audio conversations
(aka "Internet telephony") and videoconferencing.</t>
<t>The first attempts to build this were dependent on special networks,
special hardware and custom-built software, often at very high prices or
at low quality, placing great demands on the infrastructure.</t>
<t>As the available bandwidth has increased, and as processors and other
hardware has become ever faster, the barriers to participation have
decreased, and it is possible to deliver a satisfactory experience on
commonly available computing hardware.</t>
<t>Still, there are a number of barriers to the ability to communicate
universally - one of these is that there are, as of yet, no single set
of communication protocols that all agree should be made available for
communication; another is the sheer lack of universal identification
systems (such as is served by telephone numbers or email addresses in
other communications systems).</t>
<t>Development of "The Universal Solution" has proved hard, however, for
all the usual reasons. This memo aims to take a more building-block-
oriented approach, and try to find consensus on a set of substrate
components that we think will be useful in any real-time communications
systems.</t>
<t>The last few years have also seen a new platform rise for deployment
of services: The browser-embedded application, or "Web application". It
turns out that as long as the browser platform has the necessary
interfaces, it is possible to deliver almost any kind of service on
it.</t>
<t>Traditionally, these interfaces have been delivered by plugins, which
had to be downloaded and installed separately from the browser; in the
development of HTML5, much promise is seen by the possibility of making
those interfaces available in a standardized way within the browser.</t>
<t>Other efforts, for instance the W3C Web Applications and Device API
working groups, focus on making standardized APIs and interfaces
available, within or alongside the HTML5 effort, for those functions;
this memo concentrates on specifying the protocols and subprotocols that
are needed to specify the interactions that happen across the
network.</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Protocol Requirements">
<t>The section defines the set of protocols and selected subset profiles
of these protocols that RTC-WEB client applications will need to
implement. This set of protocols forms the requirements for the
controlling APIs in [Section 4]. At a high level this section is split
into five subsections that address requirements for RTC-WEB client
application: connection management, signaling protocols, codec
requirements, transports for real time media such as audio and video and
transports for non media data .</t>
<section title="Connection Management Requirements">
<t>It is quite probable that many RTC-WEB client applications, such as
web browsers will be deployed behind a NAT. To set up secure data
plane sessions, all RTC-WEB client application implementations will
use ICE <xref target="RFC5245"></xref> or ICE-Lite Section 2.7 of
<xref target="RFC5245"></xref>. ICE is leveraged here to address the
security concerns discussed in [section] <xref
target="Security"></xref>.</t>
<t>There are two deployment scenarios for RTC-WEB client applications.
The first scenario is when applications are deployed behind NAT and
have to worry about NAT traversal. The second scenario is when the
application is not behind a NAT, such as an RTC-WEB application that
is always connected to the public Internet. As stated in section 2.7
of <xref target="RFC5245"></xref>, ICE requires that both endpoints to
support it in order for ICE to be used on a call.</t>
<t>With regards to RTC-WEB client applications, all applications that
are deployed behind a NAT or do not have a public IP address are
REQUIRED to support ICE <xref target="RFC5245"></xref>, applications
that are not behind a NAT and have a public IP address are REQUIRED to
support ICE-Lite and MAY fully support ICE. RTC-WEB client
applications that fully support ICE are REQUIRED to support AGGRESSIVE
NOMINATION, and MAY support REGULAR NOMINATION.</t>
<t>Implicit to supporting ICE, all RTC-WEB client applications are
REQUIRED to implement Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs) (STUN) <xref
target="RFC3489"></xref> and Traversal Using Relays around NAT (TURN)
<xref target="RFC5766"></xref>.</t>
<t>[Open Issue: there is a strong interest to define a TURN-like
protocol that looks like HTTP to intermediaries, so that media can be
tunneled over HTTP. Should this be done?]</t>
</section>
<section title="Signaling Protocol Requirements">
<t>This section covers the signaling protocol to be used by RTC-WEB
applications. To ensure interoperability not just between RTC-WEB
applications, but with legacy IPPBX phone systems as well, a small
subset of SIP will be REQUIRED for all RTC-WEB client application
implementations. In addition to the subset of SIP specification <xref
target="RFC3261"></xref>, RTC-WEB client application implementations
will be REQUIRED to support DNS resolutions as specified in <xref
target="RFC3263"></xref> and the offer/answer model with SDP as
specified in <xref target="RFC3264"></xref>.</t>
<section title="Client Application SIP Requirements">
<t>This section focuses on the subset of SIP functionality that will
exist within all RTC-WEB client applications. The following User
Agent Client (UAC) subset of the SIP specification <xref
target="RFC3261"></xref> is REQUIRED.</t>
<t><list style="symbols">
<t>General User Agent Behavior - [Section 8]</t>
<t>Registration - [Section 10]</t>
<t>Client Transaction - [Section 17.1]</t>
<t>Canceling a Request - [Section 9.1]</t>
<t>Terminating a Session - [Section 15.1], [Section 15.1.1]</t>
<t>3.XX Redirect Responses - [Section 8.1.3.4]</t>
<t>TLS - [Section 26.3.1]</t>
<t>Outbound Proxy</t>
</list></t>
</section>
<section title="Client Application Optional SIP Support">
<t>In the SIP specification <xref target="RFC3261"></xref>, the SIP
features listed below are required for all UAC implementations.
RTC-WEB client applications are not a fully featured SIP UAC and
will only be implementing a subset of the SIP specification. Thusly,
unlike SIP UACs, the following list of SIP features is to be
considered OPTIONAL for RTC-WEB client application
implementations.</t>
<t><list style="symbols">
<t>INVITEs without an offer</t>
<t>re-INVITEs – [Section 14.1]</t>
<t>forking – [Section 19.3]</t>
<t>S/MIME – [Section 23]</t>
<t>SIPS URI Scheme – [Section 26.2.2]</t>
</list></t>
</section>
<section title="Required SIP Methods">
<t>This section outlines the REQUIRED SIP methods for all RTC-WEB
client applications.</t>
<t><list style="symbols">
<t>INVITE – <xref target="RFC3261"></xref> [Section
13]</t>
<t>REGISTER – <xref target="RFC3261"></xref> [Section
10]</t>
<t>ACK - <xref target="RFC3261"></xref> [Section 13.2]</t>
<t>CANCEL - <xref target="RFC3261"></xref> [Section 13.2]</t>
<t>BYE - <xref target="RFC3261"></xref> [Section 13.2]</t>
<t>UPDATE – <xref target="RFC3311"></xref></t>
</list></t>
</section>
<section title="Multipart SIP Message Requirements">
<t>For handling SIP messages RTC-WEB client applications are
required to implement the multipart MIME handling scheme as
specified in <xref target="RFC5621"></xref>.</t>
</section>
<section title="SIP Identity Requirements">
<t>Identity, for the purposes of this section, is defined as a SIP
URI. There are two areas concerning SIP identity this specification
will address.</t>
<t>The first area covers validation of the message originator. To
securely validate a the identity of a SIP message originator, all
RTC-WEB client applications are REQUIRED to implement the mechanism
specified in <xref target="RFC4474"></xref>.</t>
<t>To support cases were the identify of a caller/callee may change,
such as when a call is parked and transferred from the original
callee to another party, all RTC-WEB client applications are
REQUIRED to implement the identity mechanism specified in <xref
target="RFC4916"></xref>. <xref target="RFC3261"></xref>implicitly
REQUIRES the implementation of the UPDATE method as specified in
<xref target="RFC3311"></xref></t>
</section>
<section title="SIP Network Address Traversal">
<t>RTC-WEB client applications MUST support Network Address
Translator (NAT) traversal. This section will address SIP-related
areas to support NAT traversal.</t>
<t>As called for in [3.1] RTC-WEB client applications will implement
STUN. To support client-managed connections, STUN-based keep-alives
as specified in <xref target="RFC5626"></xref> are REQUIRED.</t>
<t>When SIP is used with UDP, responses to requests are returned to
the source address the request came from, and to the port written
into the topmost Via header field value of the request. This
behavior is not desirable when the RTC-WEB client application is
behind a Network Address Translator (NAT). To address UDP traversal
problem the "rport" extension as specified in <xref
target="RFC3581"></xref> is REQUIRED.</t>
</section>
</section>
<section title="Codec Requirements">
<t>This section covers the audio and video codec requirements for
RTC-WEB client applications. To ensure a baseline level of
interoperability between RTC-Web applications, a minimum set of
required codes is specified below. While this section specifies the
codecs that will be supported by all RTC-Web application
implementations, it leaves the question of supporting additional
codecs to the will of the implementer.</t>
<section title="Audio Codec Requirements">
<t>RTC-WEB applications are REQUIRED to implement the following
audio codecs.</t>
<t><list style="symbols">
<t>PCMA/PCMU - see section 4.5.14 of <xref
target="RFC3551"></xref></t>
<t>Telephone-event - <xref target="RFC4734"></xref></t>
<t>Opus [draft-ietf-codec-opus]</t>
</list></t>
<t>Implementations of the PCMU and PMCA codecs are REQUIRED to
support 1 channel with a rate of 8000 and a ptime of 20.</t>
<t>The following codecs are OPTIONAL for RTC-WEB application
implementations.</t>
<t><list style="symbols">
<t>G729</t>
<t>G722</t>
<t>G722.1</t>
<t>G723</t>
<t>AMR</t>
<t>AMR-WB</t>
<t>iLBC</t>
<t>L16</t>
</list> [Open Issue: minimum profile and identifying any
additional mandatory to implement audio codecs.]</t>
</section>
<section title="Video Codec Requirements">
<t>RTC-WEB applications are REQUIRED to implement the following
video codecs.</t>
<t><list style="symbols">
<t>VP8 [I-D.westin-payload-vp8]</t>
</list></t>
<t>The following codecs are OPTIONAL for RTC-WEB application
implementations.</t>
<t><list style="symbols">
<t>H.263</t>
<t>H.264-AVC</t>
<t>H.264-SVC</t>
</list>[Open Issue: For the mandatory to implement video codec(s)
what is the minimum profile?]</t>
</section>
</section>
<section title="Real-Time Media Transport Requirements">
<t>This section defines the real-time media transport requirements for
RTC-Web client application implementation. This section breaks down
the RTC-WEB RTP requirements into several sections. The sections cover
the RTP requirements for: profile, optimizations, extensions,
transport robustness and rate control.</t>
<t>[OPEN ISSUE: identify missing requirements]</t>
<section title="RTP Profile">
<t>RTC-Web applications to will need to provide a secure,
interoperable, bandwidth friendly, media transport profile. The
Secure Audio-visual Profile Feedback (SAVPF) as defined in <xref
target="RFC5124"></xref> will meet the needs of RTC-Web applications
by providing media encryption, interoperability and a flexible,
bandwidth conscious RTCP packet transmission model. All RTC-Web
applications are REQUIRED to implement SAVPF. Requiring the
implementation of SAVPF also means that RTC-Web applications MUST
implicitly support Audio-visual Profile Feedback (AVPF) <xref
target="RFC4585"></xref>, Audio-visual Profile (AVP) <xref
target="RFC3551"></xref> and Secure Audio-visual Profile (SAVP)
<xref target="RFC3711"></xref>.</t>
<section title="Profile Encryption Mechanism">
<t>SAVPF supports SRTP by providing media encryption, integrity
protection, replay protection and a limited form of source
authentication. Though the SAVPF profile does support secure media
transport, it does not specify an encryption keying mechanism. To
support keying for SRTP, WEB-RTC application implementors are
REQUIRED to implement DTLS-SRPT <xref
target="RFC5764"></xref>.</t>
</section>
</section>
<section title="RTP Optimizations">
<t>This section describes the optimization requirements for RTP
within RTC-Web applications.</t>
<section title="RTP and RTCP Multiplexing">
<t>Historically, RTP and RTCP have been run on separate UDP ports.
With the increased use of Network Address Port Translation (NAPT)
so have the problems increased for maintaining multiple, costly
NAT bindings for each UDP port. This dual UDP port paradigm also
complicates firewall administration, since multiple ports must be
opened to allow for RTP traffic. To reduce these costs and session
setup times, support for multiplexing RTP data packets and RTCP
control packets on a single port <xref target="RFC5761"></xref> is
REQUIRED.</t>
<t>Note that the use of RTP and RTCP multiplexed on a single port
ensures that there is occasional traffic sent on that port, even
if there is no active media traffic. This may be useful to
keep-alive NAT bindings.</t>
</section>
<section title="Reduced-Size RTCP">
<t>RTCP packets are usually sent as compound RTCP packets and
<xref target="RFC3550"></xref> demands that the RTCP compound
packets always start with a Sender Report (SR) or Receiver Report
(RR) packet. The SR and RR packets provide reception quality
statistics and increase the mean RTCP packet size. Because the
mean compound RTCP packet size is larger, the frequency at which
RTCP packets can be sent within the RTCP bandwidth share
decreases. The decreased transmission frequency creates a
performance bottleneck that is especially noticeable when using
frequent feedback messages.</t>
<t>As mentioned in section [Add ref] RTC-Web applications will be
required to implement SAVPF, which implicitly requires feedback.
<xref target="RFC5506"></xref> specifies how to reduce the mean
RTCP message and allow for more frequent feedback. Frequent
feedback, in turn, is essential to make real-time application
quickly aware of changing network conditions and allow them to
adapt their transmission and encoding behavior. Support for <xref
target="RFC5506"></xref> is REQUIRED</t>
</section>
<section title="Symmetric RTP/RTCP">
<t>RTP entities choose the RTP and RTCP transport addresses (IP
addresses and port numbers), to bind to and receive packets on.
However when sending RTP and RTCP packets, senders may use an IP
address or port number that is different than the one specified
for receiving packets. Using different transport addresses is
problematic with regards to NAT traversal. The NAT traversal
problem can be alleviated using symmetric RTP/RTCP <xref
target="RFC4961"></xref>. Symmetric RTP/RTCP requires that the
transport addresses for sending and receiving RTP/RTCP packets are
identical. All RTC-WEB client applications are REQUIRED to
implement Symmetric RTP/RTCP <xref target="RFC4961"></xref>.</t>
</section>
<section title="CNAME Generation">
<t>The RTCP Canonical Name (CNAME) provides a persistent
transport-level identifier for an RTP endpoint. While the
Synchronization Source (SSRC) identifier for an RTP endpoint may
change if a collision is detected, or when the RTP application is
restarted, it's RTCP CNAME is meant to stay unchanged, so that RTP
endpoints can be uniquely identified and associated with their RTP
media streams. For proper functionality, RTCP CNAMEs should be
unique within the participants of an RTP session.</t>
<t>The RTP specification <xref target="RFC3550"></xref> includes
guidelines for choosing a unique RTP CNAME. These guidelines are
not sufficient in the presence of NAT devices or with regards to
addressing privacy concerns resulting from the long-term,
persistent identifiers.</t>
<t>To address the shortcomings of CNAME selection in<xref
target="RFC3550"></xref>, it is RECOMMENDED that RTP CNAME
generation follows the approach specified in section 5 of <xref
target="RFC6222"></xref>.</t>
<t>For RTC-WEB client applications, such as a web browser, it may
not be possible to retrieve the EUI-64 identifier or the host
system's MAC address which is needed to fulfill the CNAME
generation procedure outlined in section 5 of <xref
target="RFC6222"></xref>. As an alternative to the EUI-64/MAC
address, RTC-WEB client applications MAY generate and use a random
number for the unique CNAME generation procedure.</t>
</section>
</section>
<section title="RTP Extensions">
<t>.This section describes the RTP extensions that could be very
useful within the RTC-WEB context.</t>
<section title="Conferencing Extensions">
<t>RTC-Web applications will support conferencing capabilities.
While this document remains silent regarding what conferencing
topology should be supported for RTC-Web applications, the
following section will provide guidance around RTP extensions to
support centralized conferencing.</t>
<t>For more information on RTP conferencing topologies please
refer to <xref target="RFC5117"></xref></t>
<section title="FIR RTCP Feedback Message">
<t>The Full Intra Request (FIR) command and message are defined
in sections 3.5.1 and 4.3.1 of <xref target="RFC5104"></xref>.
FIR messages will request that the currently distributed session
participants send new intra coded pictures to the mixer. FIR is
used when switching between sources to ensure that the receivers
can decode the video or other predicted media encoding with long
prediction chains. It is RECOMMENDED that the FIR message is
supported.</t>
</section>
<section title="PLI RTCP Feedback Message">
<t>The Picture Loss Indicator (PLI) is defined in Section 6.3.1
of <xref target="RFC4585"></xref>. PLI messages tell the encoder
that a receiver has lost the decoder context and would like it
repaired. It is RECOMMENDED that the PLI message is
supported.</t>
</section>
<section title="TMMBR RTCP Feedback Message">
<t>The Temporary Maximum Media Stream Bit Rate Request (TMMBR,
"timber") message is defined in sections 3.5.4 and 4.2.1 of
<xref target="RFC5104"></xref>. A receiver, translator, or mixer
uses the TMMBR to request a sender to limit the maximum bit rate
for a media stream to, or below, the provided value. An example
of using TMMBR would be for an RTP mixer to constrain the media
sender’s bit rate to fit within the lower bit rate range
of other session participants. It is RECOMMENDED that the TMMBR
message be supported.</t>
</section>
</section>
<section title="Header Extensions">
<t>This section describes the requirements for RTC-WEB RTP header
extensions. For all RTC-WEB RTP header extensions it is REQUIRED
that they are formatted and signaled according to the general
mechanism defined in <xref target="RFC5285"></xref>.</t>
<t>[Open Issue: should any of the following headers be added to
the list:</t>
<t><list style="symbols">
<t>Transmission time offsets<xref target="RFC5450"></xref></t>
<t>Associating time-codes with RTP streams <xref
target="RFC5484"></xref> [Remove?]</t>
</list>Open Issue: There is also ongoing work to define RTP
header extensions for providing audio levels: <list
style="symbols">
<t>From the media sender to the mixer
[I-D.ietf-avtext-client-to-mixer-audio-level]</t>
<t>From a mixer to a receiver
[I-D.ietf-avtext-mixer-to-client-audio-level]</t>
</list>Which, if any of the above should be required?
optional?</t>
<t>]</t>
<section title="Rapid Synchronization">
<t>Basic RTP session synchronization as described in <xref
target="RFC3550"></xref> can be slow. To improve synchronization
performance and maintain relative backwards compatibility it is
RECOMMENDED that the rapid RTP synchronization extensions
described in <xref target="RFC6051"></xref> be implemented.</t>
</section>
</section>
</section>
<section title="RTP Transport Robustness">
<t>This section identifies tools that can be used to add robustness
to the RTP flows. Adding robustness to the RTP flow can reduce
packet loss and thus have a positive impact upon media quality.</t>
<section title="RTP Retransmission">
<t>The retransmission scheme in RTP allows for flexibility of
retransmissions. From the receiving side, only selected missing
packets can be requested. From the sending side, packets can be
prioritized based upon the senders knowledge of the
receiver’s missing packets. Support for RTP retransmission
as defined by <xref target="RFC4588"></xref> is RECOMMENDED.</t>
<t>[Open Issue: is <xref target="RFC4588"></xref> the way we want
to tackle this issue?]</t>
</section>
<section title="Forward Error Correction">
<t>[Open issue - should there be a FEC scheme recommendation?]</t>
</section>
<section title="Multicast">
<t>RTC-WEB client applications support for multicast RTP is NOT
REQUIRED.</t>
</section>
</section>
<section title="RTP Rate Control">
<t>[OPEN ISSUE - There are currently no available, standardized RTP
rate control mechanism that uses media adaptation. Having a
mechanism in place will be REQUIRED for RTC-WEB applications and
which means there is a need for the IETF to produce this
specification.</t>
<t>A potential starting point for defining a solution is "RTP with
TCP Friendly Rate Control" [rtp-tfrc].]</t>
</section>
</section>
<section title="Non-Media Data Transport Requirements">
<t>The RTC-WEB will enable for rich voice and video communications
from client applications, such as a web browser. One of the natural
extensions of the RTC-WEB and the work emerging from the HTML5
community is video games. Video games have a similar stringent
real-time requirement for exchanging non-media data types such as a
player’s screen position.</t>
<t>The question of how best to handle non-media data types has been
raised. There have been proposals to address this problem. Common to
all proposals is how the data transport session is set up, using ICE
<xref target="RFC5245"></xref> in a similar manner to that of RTP
<xref target="RFC3550"></xref>. The proposals vary from once the
session is set up; one proposal is just to use a thin shim on top of
UDP or DTLS to de-multiplex the packets from other packets such as RTP
on the same connection. Another proposal is DTLS over DCCP over UDP
with some appropriate congestion control scheme chosen for DCCP.
Lastly there has been a proposal to define a data codec to carry the
data in RTP.</t>
<section title="Non-Media Data In RTP">
<t>This section will answer the question regarding the addition of
non-media data types into an RTC-WEB client application initiated
RTP session.</t>
<t>RTP by design adheres to the application level framing
architectural principle. This principle requires that RTP payload
formats be specified. By requiring specific payload formats RTP
provides a mechanism to optimize the transmission of encoded media.
Other than this optimization there is no congestion control
mechanisms for RTP.</t>
<t>This principle also implies that if a payload format cannot be
specified, as the case is with generic data, it breaks one of the
fundamental architectural principles of RTP and makes optimization
impossible. Given that the ability to optimize the transmission of
non-media data types is lost and there are no capabilities for
congestion control within RTP, it follows that there is no benefit
to using RTP instead of a more general data transport such as UDP.
Until non-media data payload formats are created, the use of RTP as
a non-media data transport SHALL NOT be used in conjunction with any
RTC-WEB client application implementation.</t>
<t>[Open issue: There has been mention of actually creating new
payload formats for non-media data types. If new payload formats are
actually created for specific types of non-media data, the
requirement above would still stand as the application level framing
principle would be preserved and the new formats would have to
adhere to the principle. Any new formats would be specified outside
of this document but referred to]</t>
</section>
<section title="Transporting Non-Media Data">
<t>[OPEN issue: need further discussion around this area]</t>
<t>There have been some ideas proposed but nothing has emerged as
the dominant paradigm. The current thinking is that, for RTC-WEB
client applications, RTP is not an option for non-media data types
that do not have a payload format specification. Without a payload
format specification a workable solution would resemble something
that allows datagrams to be transmitted via a secure,
congestion-controlled, unreliable transport mechanism.</t>
<section title="Proposed Solutions for Non-Media Data Transport">
<t>One of the current proposed solutions could meet the
requirements for a non-media data type transport for RTC-WEB
client application is to use a DCCP via the following
specifications:</t>
<t><list style="symbols">
<t>DCCP <xref target="RFC4340"></xref> using TCP <xref
target="RFC4341"></xref> or TFRC <xref
target="RFC4342"></xref> for congestion control</t>
<t>DTLS for DCCP <xref target="RFC5238"></xref></t>
<t>DCCP over UDP [draft-ietf-dccp-udpencap]</t>
</list></t>
<t>The maturity of available implementations of DCCP is of concern
along with the partiality of this proposed solution. Another way
of tackling the problem of non-media data transport is to push the
requirements into the RTC-WEB client application
implementation.</t>
<t>The following is a proposed set of REQUIRED RTC-WEB client
application non-media data transport requirements.</t>
<t><list style="symbols">
<t>Support for a broad congestion control constraints are
REQUIRED, it is RECOMMENDED that implementors support either
TFRC <xref target="RFC5348"></xref> or TFRC-SP <xref
target="RFC4828"></xref>.</t>
<t>Support for full congestion control is RECOMMENDED, the
specific implementation is left to the RTC-WEB client
application implementor.</t>
<t>Support for DTLS over UDP is REQUIRED</t>
</list></t>
<t>As an example of how these proposed requirements could be
implemented within an RTC-WEB client application, lets explore a
web browser-based implementation. In this specific implementation,
the web browser would provide DTLS over UDP and implement a broad
congestion control solution such as TFRC or TFRC-SP. This
implementation will yield a coarse-grained congestion controlled
non-media data transport solution that is accessible via
JavaScript API calls. These non-media data transport capabilities
would provide a flexible solution for web developers to build a
full congestion control solution into their WEB-RTC client
application.</t>
<t>[Open Issue: Given that there is no consensus with regards to a
transport solution, this topic needs further discussion.</t>
<t>Open Issue: Areas for further discussion:</t>
<t><list style="symbols">
<t>Unreliable datagram transport – should this be UDP,
SCTP or DCCP?</t>
<t>Congestion control mechanisms – DCCP and SCTP
something else?</t>
<t>Protection of data confidentiality and integrity –
DTLS</t>
<t>Receiver consent mechanisms for data transmission</t>
</list>]</t>
</section>
</section>
</section>
</section>
<section title="API Requirements">
<t>NOT Ready - need to decide on protocols first, API comes after
that</t>
<t>RTP</t>
<t>The API needs to allow the DSCP REF for each RTP or media stream to
be set.</t>
<t>The API needs to allow the browser app to observer and control the
SSRC values in the RTP.</t>
<t>Codec</t>
<t>The API needs to support the following OPTIONAL codecs: H263-2000,
H264, H264-SVC, raw and VP8.</t>
<t>The API needs to support the following OPTIONAL codecs: G729, G722,
G7221, G723, AMR, AMR-WB, iLBC, L16 and opus.</t>
<t></t>
</section>
<section title="Legacy VoIP Interoperability">
<t>There is no way to meet all the security requirements and maintain
comparability with all legacy VoIP equipment. This draft tries to
minimize the impedance mismatch. The requirements here would allow
interoperability with legacy VoIP equipment as long as that equipment
either directly supported, or was fronted by an SBC that supported, the
following: a CORS [W3C.WD-cors-20090317] extension for SIP, ICE or
ICE-Lite, the mandatory to implement codecs in [SECTION], supported SIP
invites containing an offer, and supported DTMF over RTP with telephone
events.</t>
<t>Of the items listed above, support for ICE-Lite has historically been
lacking in VoIP equipment, this is changing and ICE-Lite becoming
increasingly prevalent, particularly on devices designed to sit on the
edge of a domain and connect to remote user agents that may be behind
NATs. Given the increasing adoption of ICE-Lite, it could be conjectured
that a substantial fraction of VoIP equipment meets the RTC-WEB
interoperability list except for the CORS extensions.</t>
<t>For an edge device that was willing to receive SIP call from others,
implementing the CORS is pretty trivial. When the UAS receives a SIP
options request with an Origin header, it checks whether the header
field value is on the white list, and if it is then the UAS copies the
value to the Access-Control-Allow-Origin header field value in the
response. For many situations the white list would be everything, while
for others it would be just the list of websites that are expected to
originate calls to this SIP device.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Because there are a number of security issues, considerations and
requirements for RTC-WEB client applications there is a draft that
specifically addresses the RTC-WEB application security considerations.
This draft defers it’s security considerations and requirements to
the security considerations for RTC-Web draft <xref
target="I-D.ekr-security-considerations-for-rtc-web"></xref>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Harald Alvestrand, Magnus Westerlund, Colin Perkins,
Joerg Ott for a signifcant amount of text and contributed ideas on this
topic.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5124.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4916.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5761.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3581.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5506.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4961.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6222.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5117.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5104.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5450.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5285.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6051.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4588.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5348.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4828.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4341.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4342.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5484.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3489.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3311.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5621.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5626.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5238.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4734.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5764.xml'?>
<reference anchor="I-D.ekr-security-considerations-for-rtc-web">
<front>
<title abbrev="RTC-Web Security">Security Considerations for
RTC-Web</title>
<author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
<organization>RTFM, Inc.</organization>
<address>
<postal>
<street>2064 Edgewood Drive</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94303</code>
<country>USA</country>
</postal>
<phone>+1 650 678 2350</phone>
<email>ekr@rtfm.com</email>
</address>
</author>
<date day="30" month="May" year="2011" />
<area>RAI</area>
<workgroup>RTC-Web</workgroup>
<abstract>
<t>The Real-Time Communications on the Web (RTC-Web) working group
is tasked with standardizing protocols for real-time
communications between Web browsers. The two major use cases for
RTC-Web technology are real-time audio and/or video calls and
direct data transfer. Unlike most conventional real-time systems
(e.g., SIP-based soft phones) RTC-Web communications are directly
controlled by some 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 RTC-Web threat
model and defines an architecture which provides security within
that threat model.</t>
</abstract>
<note title="Legal">
<t>THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE
PROVIDED ON AN “AS IS” BASIS AND THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING
TASK FORCE, DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:46:37 |