One document matched: draft-cbran-rtcweb-media-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-media-00"
ipr="noDerivativesTrust200902">
<front>
<title abbrev="Abbreviated-Title">RTC-Web Media Transport
Requirements</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="29" month="June" year="2011" />
<abstract>
<t>This document outlines the media transport protocols and requirements
for RTC-Web client applications.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>An integral part of the success and adoption of the Real-Time
Communications Web (RTC-WEB) will be the interoperability between
RTC-Web applications. This specification will focus on the media
transport requirements for RTC-Web client applications.</t>
<t>The media transport requirements fit into a series of specifications
have been created to address RTC-Web negotiation and signaling
protocols, security requirements, non-media data transmission and use
cases. More information on the RTC-Web can be found here:</t>
<t>[TODO put links to supporting drafts here]</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="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 multiple RTP streams on a
single UDP port <xref
target="I-D.rosenburg-jennings-rtp-mux"></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></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 title="Audio Levels">
<t>These RTP header extensions provide a mechanism to indicate the
audio level within the same RTP packets as the audio data they
pertain to.</t>
<t>In large conferences, when clients send audio levels of the
audio sample contained within the RTP packet to the mixer, it can
reduce the load on the audio mixer as resources for decoding and
measuring audio streams are not needed. Because of the performance
gains at scale, it is RECOMMENDED that the extension described in
<xref target="I-D.ietf-avtext-client-to-mixer-audio-level"></xref>
be implemented.</t>
<t>Clients can also optimize performance if the RTP packets sent
from the mixer contain the audio levels. It is OPTIONAL for mixers
to implement the extension described in <xref
target="I-D.ietf-avtext-mixer-to-client-audio-level"></xref>.</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. Is has been proposed that RTC-WEB applications
could use the RTP retransmission as defined by <xref
target="RFC4588"></xref>, this retransmission scheme is problematic
for RTC-Web applications on two fronts. The first problem area is
the additional latency added by <xref target="RFC4588"></xref> will
exceed the latency threshold for interactive voice and video. The
second issue is involves the undesirable increase in packet
transmission at the point when congestion occurs. Until the two
issues are addressed, implementing <xref target="RFC4588"></xref>
for RTC-Web applications is NOT RECOMMENDED.</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="Legacy VoIP Interoperability">
<t>The use of RTP as specified above will maximize the interoperability
capabilities between RTC-Web client applications and legacy VoIP
systems.</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>This draft incorporates ideas and text from various other drafts. In
particularly we would like to acknowledge, and say thanks for, work we
incorporated from Harald Alvestrand, Magnus Westerlund, Colin Perkins,
and Joerg Ott.</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.3711.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.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.5484.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>
<reference anchor="I-D.ietf-avtext-client-to-mixer-audio-level">
<front>
<title>A Real-Time Transport Protocol (RTP) Header Extension for
Client-to-Mixer Audio Level Indication</title>
<author fullname="Jonathan Lennox" initials="J" surname="Lennox">
<organization>Vidyo</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Emil Ivov" initials="E" surname="Ivov">
<organization>Jitsi</organization>
</author>
<author fullname="Enrico Marocco" initials="E" surname="Marocco">
<organization>Telecom Itialia</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="March" year="2011" />
</front>
</reference>
<reference anchor="I-D.ietf-avtext-mixer-to-client-audio-level">
<front>
<title>A Real-Time Transport Protocol (RTP) Header Extension for
Mixer-to- Client Audio Level Indication</title>
<author fullname="Emil Ivov" initials="E" surname="Ivov">
<organization>Jitsi</organization>
</author>
<author fullname="Enrico Marocco" initials="E" surname="Marocco">
<organization>Telecom Itialia</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Jonathan Lennox" initials="J" surname="Lennox">
<organization>Vidyo, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="May" year="2011" />
</front>
</reference>
<reference anchor="I-D.rosenburg-jennings-rtp-mux">
<front>
<title abbrev="RTP Mux">Multiplexing of Real-Time Transport Protocol
(RTP) Traffic for Browser based Real-Time Communications
(RTC)</title>
<author fullname="Jonathan Rosenberg" initials="J.R."
surname="Rosenberg">
<organization>Skype</organization>
<address>
<email>jdrosen@skype.net</email>
<uri>http://www.jdrosen.net</uri>
</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 month="June" year="2011" />
<area>RAI</area>
<workgroup>RTCWEB</workgroup>
<keyword>SIP</keyword>
<keyword>RTP</keyword>
<abstract>
<t>This document argues that multiplexing of voice and video
traffic over a single RTP session should be specified as the
baseline mode of operation for multimedia traffic in RTC web.</t>
</abstract>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:05:14 |