One document matched: draft-cbran-rtcweb-media-00.txt
Network Working Group C. Bran
Internet-Draft C. Jennings
Intended status: Standards Track Cisco
Expires: December 31, 2011 June 29, 2011
RTC-Web Media Transport Requirements
draft-cbran-rtcweb-media-00
Abstract
This document outlines the media transport protocols and requirements
for RTC-Web client applications.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bran & Jennings Expires December 31, 2011 [Page 1]
Internet-Draft Abbreviated-Title June 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Real-Time Media Transport Requirements . . . . . . . . . . . . 3
3.1. RTP Profile . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Profile Encryption Mechanism . . . . . . . . . . . . . 4
3.2. RTP Optimizations . . . . . . . . . . . . . . . . . . . . 4
3.2.1. RTP and RTCP Multiplexing . . . . . . . . . . . . . . 4
3.2.2. Reduced-Size RTCP . . . . . . . . . . . . . . . . . . 4
3.2.3. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 5
3.2.4. CNAME Generation . . . . . . . . . . . . . . . . . . . 5
3.3. RTP Extensions . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Conferencing Extensions . . . . . . . . . . . . . . . 6
3.3.2. Header Extensions . . . . . . . . . . . . . . . . . . 6
3.4. RTP Transport Robustness . . . . . . . . . . . . . . . . . 7
3.4.1. RTP Retransmission . . . . . . . . . . . . . . . . . . 7
3.4.2. Forward Error Correction . . . . . . . . . . . . . . . 8
3.4.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 8
3.5. RTP Rate Control . . . . . . . . . . . . . . . . . . . . . 8
4. Legacy VoIP Interoperability . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Bran & Jennings Expires December 31, 2011 [Page 2]
Internet-Draft Abbreviated-Title June 2011
1. Introduction
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.
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:
[TODO put links to supporting drafts here]
2. Terminology
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 RFC 2119 [RFC2119].
3. Real-Time Media Transport Requirements
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.
[OPEN ISSUE: identify missing requirements]
3.1. RTP Profile
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 [RFC5124] 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) [RFC4585], Audio-visual Profile (AVP)
[RFC3551] and Secure Audio-visual Profile (SAVP) [RFC3711].
Bran & Jennings Expires December 31, 2011 [Page 3]
Internet-Draft Abbreviated-Title June 2011
3.1.1. Profile Encryption Mechanism
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 [RFC5764].
3.2. RTP Optimizations
This section describes the optimization requirements for RTP within
RTC-Web applications.
3.2.1. RTP and RTCP Multiplexing
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
[I-D.rosenburg-jennings-rtp-mux] is REQUIRED.
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.
3.2.2. Reduced-Size RTCP
RTCP packets are usually sent as compound RTCP packets and [RFC3550]
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.
As mentioned in section [Add ref] RTC-Web applications will be
required to implement SAVPF, which implicitly requires feedback.
[RFC5506] 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
Bran & Jennings Expires December 31, 2011 [Page 4]
Internet-Draft Abbreviated-Title June 2011
behavior. Support for [RFC5506] is REQUIRED
3.2.3. Symmetric RTP/RTCP
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 [RFC4961]. 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 [RFC4961].
3.2.4. CNAME Generation
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.
The RTP specification [RFC3550] 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.
To address the shortcomings of CNAME selection in[RFC3550], it is
RECOMMENDED that RTP CNAME generation follows the approach specified
in section 5 of [RFC6222].
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 [RFC6222]. 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.
3.3. RTP Extensions
This section describes the RTP extensions that could be very useful
within the RTC-WEB context.
Bran & Jennings Expires December 31, 2011 [Page 5]
Internet-Draft Abbreviated-Title June 2011
3.3.1. Conferencing Extensions
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.
For more information on RTP conferencing topologies please refer to
[RFC5117]
3.3.1.1. FIR RTCP Feedback Message
The Full Intra Request (FIR) command and message are defined in
sections 3.5.1 and 4.3.1 of [RFC5104]. 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.
3.3.1.2. PLI RTCP Feedback Message
The Picture Loss Indicator (PLI) is defined in Section 6.3.1 of
[RFC4585]. 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.
3.3.1.3. TMMBR RTCP Feedback Message
The Temporary Maximum Media Stream Bit Rate Request (TMMBR, "timber")
message is defined in sections 3.5.4 and 4.2.1 of [RFC5104]. 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.
3.3.2. Header Extensions
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 [RFC5285].
[Open Issue: should any of the following headers be added to the
list:
Bran & Jennings Expires December 31, 2011 [Page 6]
Internet-Draft Abbreviated-Title June 2011
o Transmission time offsets[RFC5450]
o Associating time-codes with RTP streams [RFC5484] [Remove?]
3.3.2.1. Rapid Synchronization
Basic RTP session synchronization as described in [RFC3550] can be
slow. To improve synchronization performance and maintain relative
backwards compatibility it is RECOMMENDED that the rapid RTP
synchronization extensions described in [RFC6051] be implemented.
3.3.2.2. Audio Levels
These RTP header extensions provide a mechanism to indicate the audio
level within the same RTP packets as the audio data they pertain to.
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
[I-D.ietf-avtext-client-to-mixer-audio-level] be implemented.
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
[I-D.ietf-avtext-mixer-to-client-audio-level].
3.4. RTP Transport Robustness
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.
3.4.1. RTP Retransmission
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 [RFC4588], this
retransmission scheme is problematic for RTC-Web applications on two
fronts. The first problem area is the additional latency added by
[RFC4588] 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 [RFC4588] for RTC-Web
Bran & Jennings Expires December 31, 2011 [Page 7]
Internet-Draft Abbreviated-Title June 2011
applications is NOT RECOMMENDED.
3.4.2. Forward Error Correction
[Open issue - should there be a FEC scheme recommendation?]
3.4.3. Multicast
RTC-WEB client applications support for multicast RTP is NOT
REQUIRED.
3.5. RTP Rate Control
[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.
A potential starting point for defining a solution is "RTP with TCP
Friendly Rate Control" [rtp-tfrc].]
4. Legacy VoIP Interoperability
The use of RTP as specified above will maximize the interoperability
capabilities between RTC-Web client applications and legacy VoIP
systems.
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
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
[I-D.ekr-security-considerations-for-rtc-web].
Bran & Jennings Expires December 31, 2011 [Page 8]
Internet-Draft Abbreviated-Title June 2011
7. Acknowledgements
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.
8. Normative References
[I-D.ekr-security-considerations-for-rtc-web]
Rescorla, E., "Security Considerations for RTC-Web",
May 2011.
[I-D.ietf-avtext-client-to-mixer-audio-level]
Lennox, J., Ivov, E., and E. Marocco, "A Real-Time
Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", March 2011.
[I-D.ietf-avtext-mixer-to-client-audio-level]
Ivov, E., Marocco, E., and J. Lennox, "A Real-Time
Transport Protocol (RTP) Header Extension for Mixer-to-
Client Audio Level Indication", May 2011.
[I-D.rosenburg-jennings-rtp-mux]
Rosenberg, J. and C. Jennings, "Multiplexing of Real-Time
Transport Protocol (RTP) Traffic for Browser based Real-
Time Communications (RTC)", June 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
Bran & Jennings Expires December 31, 2011 [Page 9]
Internet-Draft Abbreviated-Title June 2011
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams",
RFC 5484, March 2009.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010.
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011.
Bran & Jennings Expires December 31, 2011 [Page 10]
Internet-Draft Abbreviated-Title June 2011
Authors' Addresses
Cary Bran
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 206 256-3502
Email: cbran@cisco.com
Cullen Jennings
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408 421-9990
Email: fluffy@cisco.com
Bran & Jennings Expires December 31, 2011 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 08:43:20 |