| 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
This document outlines the media transport protocols and requirements for RTC-Web client applications.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2011.
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.
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.
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]
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].
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]
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].
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].
This section describes the optimization requirements for RTP within RTC-Web applications.
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.
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 behavior. Support for [RFC5506] is REQUIRED
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].
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.
This section describes the RTP extensions that could be very useful within the RTC-WEB context.
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]
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.
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.
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.
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:
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.
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].
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.
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 applications is NOT RECOMMENDED.
[Open issue - should there be a FEC scheme recommendation?]
RTC-WEB client applications support for multicast RTP is NOT REQUIRED.
[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].]
The use of RTP as specified above will maximize the interoperability capabilities between RTC-Web client applications and legacy VoIP systems.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
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].
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.