| Network Working Group | C. S. Perkins |
| Internet-Draft | University of Glasgow |
| Intended status: Informational | M. Westerlund |
| Expires: September 08, 2011 | Ericsson |
| J. Ott | |
| Aalto University | |
| March 07, 2011 |
RTP Requirements for RTC-Web
draft-perkins-rtcweb-rtp-usage-00
This document discusses usage of RTP in the context of RTC-WEB work. It discusses important factors of RTP to consider by other parts of the solution, it also discusses which RTP profile to support and which RTP extensions that should be supported.
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 September 08, 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 discusses RTP in the context of RTC-WEB. This include RTP's requirement on underlying transport, for example when it comes to provide multiplexing. It discusses which RTP profile that should be supported and what RTP extensions that should be supported. The importance of congestion control and media adaptation is also discussed. This document is intended as a starting point for discussing RTP features in RTC-WEB.
The work in the AVT WG has all been about providing building blocks and not specify who should use which building blocks. Selection of building blocks and functionalities can really only be done in the context of some application(s). RTC-WEB will greatly benefit in interoperability if a reasonable set of RTP functionalities and extensions are selected. For RTC-WEB we have selected RTP extensions that are suitable for a number of applications that fits the context. Thus applications such as VoIP, audio and video conferencing, and on-demand multi-media streaming are considered. Applications that rely on multicast transport has not been considered likely to be applicable to RTC-WEB, thus extensions related to multicast have been excluded.
The document is structured into different topics. For each topic one or several recommendations from the authors are done. When it comes to extensions or need for implementation support we use three levels to indicate the importance for it to be included in an RTC-WEB specification. We see it as likely that everything that is included is in fact mandated to be implemented.
When this documents discusses RTP it always include RTCP unless explicitly stated otherwise. This as RTCP is a fundamental and integral part of the protocol.
This section discusses some requirements RTP/RTCP [RFC3550] puts its underlying transport, the signalling etc.
RTP has three fundamental points of multiplexing. The first one is the RTP session, which is used to separate media of different kind or purpose. Such as Audio and Video, or the document camera and the speaker camera in video conference. This multiplexing point does not have an identifier within the RTP protocol, instead it relies on the lower layer to separate the different RTP session. Thus the most common RTP session separation is different UDP port numbers, but also IP address or other identifiers maybe used to achieve this separation. The second multiplexing point is the SSRC that separates different sources of media within a single RTP session. The third is the RTP Payload type, which identifies how the media from a particular source is encoded.
These multiplexing points area fundamental part of the design of RTP and is discussed in Section 5.2 of [RFC3550]. From that list the ones that are directly related to the importance of the RTP session as concept are 4 and 5 (from RFC 3550):
Point 4, has to do with media of different kind or purpose. The processing that can happen in an RTP mixer, translator or in an end-point is dependent on the purpose and media type of the stream. Thus there is an importance of separating such streams from each other. This could of course be achieved by other methods, like tagging SSRC values with their purpose, however there are reasons why this was not chosen. First of all it is not the simple solution, as this require additional signalling, and possibly synchronization between session peers. In addition there is the issue point 5 raises.
Point 5 has to do with enabling quality of service or traffic engineering between the media flows in different RTP sessions. By using different transport layer ports, QoS mechanism that are capable of operating on the 5-tuple (Source address, port, destination address, port, and protocol) can be used without modification on RTP.
Due to these design principle implementors of various services or applications using RTP has commonly not violated this model. If one choses to violate it today one fails to achieve interoperability with a number of existing services, applications and implementations.
Lets assume one overloads multiple RTP sessions into one by tagging the SSRC to belong to different purposes. If one would gateway that design into a legacy system, then there would be a significant issue with SSRC collision. This as the legacy system would not know about the need to avoid using the same SSRC in the different RTP sessions.
There are also various RTP mechanism that has the potential for issues if one don't have a clear separation of RTP sessions:
RTCP behavior also becomes a factor in why overloading RTP sessions is problematic. The extension mechanisms used in RTCP depends on the media streams. For example the Extended RTCP report block for VoIP is of suitable for conversational audio, but clearly not useful for Video. This has three impacts, either one get unusable reports if they are generated for streams where there are little purpose. This is maybe less likely for the VoIP report, but for example the more detailed media agnostic reports it may occur. It otherwise makes the implementation of RTCP more complex as the SSRC purpose tagging needs not only to be one the media side, but also on the RTCP reporting. Also the RTCP reporting interval and transmission scheduling will be affected.
As a conclusion not ensuring that RTP sessions are used for its intended purpose as a multiplexing point does violate the RTP design philosophy. It prevents the usage of certain RTP extensions. It will require additional extensions to function and will significantly increase the complexity of the implementation. At the same time it will significantly reduce the interoperability with current implementations.
RTP is built with the assumption of an external to RTP/RTCP signalling channel to configure the RTP sessions and its functions. The basic configuration of an RTP session consists of the following parameters:
Support for exchanging RTCP Bandwidth values to the end-points will be necessary, as described in "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth" [RFC3556], or something semantically equivalent. This also ensures that the end-points have a common view of the RTCP bandwidth, this is important as too different view of the bandwidths may lead to failure to interoperate.
As discussed in Section 2.2, the mapping between media type name, and its associated RTP payload format, and the RTP payload type number to be used for that format must be signalled as part of the session setup. An endpoint may signal support for multiple media formats, or multiple configurations of a single format, each using a different RTP payload type number. If multiple formats are signalled by an endpoint, that endpoint must be prepared to receive data encoded in any of those formats at any time. RTP does not require advance signalling for changes between formats that were signalled as part of the session setup. This is necessary for rapid rate adaptation.
The RTP profile REQUIRED to implement is "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124]. Which will mean implicit support for AVPF [RFC4585], AVP [RFC3551] and SAVP [RFC3711].
The AVPF part of SAVPF is required to get the improved RTCP timer model, that allows more flexible transmission of RTCP packets as response to events, rather than strictly according to bandwidth. This also saves RTCP bandwidth and will commonly only utilize the full amount when there is a lot of events to send feedback on.
The S part of SAVPF is for support of SRTP. This provides media encryption, integrity protection, replay protection and a limited form of source authentication. It does not contain a specific keying mechanism. So that and the set of security transforms will be required to be selected. It is possible that a security mechanism operating on a lower layer than RTP can be used instead and that should be evaluated. However, the reasons for the design of SRTP should be taken into consideration in that discussion.
RTP and RTCP are two flexible and extensible protocols that allow, on the one hand, choosing from a variety of building blocks and combining those to meet application needs, and on the other hand, create extensions where existing mechanisms are not sufficient: from new payload formats to RTP extension headers to additional RTCP control packets.
Different informational documents provide guidelines to the use and particularly the extension of RTP and RTCP, including the following: Guidelines for Writers of RTP Payload Format Specifications [RFC2736] and Guidelines for Extending the RTP Control Protocol [RFC5968].
This section discusses some optimizations that makes RTP/RTCP work better and more efficient and therefore are considered.
Historically, RTP and RTCP have been run on separate UDP ports. With the increased use of Network Address Port Translation (NAPT) this has become problematic, since maintaining multiple NAT bindings can be costly. It also complicates firewall administration, since multiple ports must be opened to allow RTP traffic. To reduce these costs and session setup times, support for multiplexing RTP data packets and RTCP control packets on a single port [RFC5761] 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 RFC 3550 demands that those compound packets always start with an SR or RR packet. However, especially when using frequent feedback messages, these general statistics are not needed in every packet and unnecessarily increase the mean RTCP packet size and thus limit the frequency at which RTCP packets can be sent within the RTCP bandwidth share.
RFC5506 "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences" [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, i.e., IP addresses and port numbers, to receive packets on and bind their respective sockets to those. When sending RTP packets, however, they may use a different IP address or port number for RTP, RTCP, or both; e.g., when using a different socket instance for sending and for receiving. Symmetric RTP/RTCP requires that the IP address and port number for sending and receiving RTP/RTCP packets are identical.
Using Symmetric RTP and RTCP [RFC4961] is REQURIED.
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, but these are not sufficient in the presence of NAT devices. In addition, some may find long-term persistent identifiers problematic from a privacy viewpoint. Accordingly, support for generating the RTP CNAME as specified in "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [I-D.ietf-avt-rtp-cnames] is RECOMMENDED, since this addresses both concerns.
There are a number of RTP extensions that could be very useful in the RTC-WEB context. One set is related to conferencing, others are more generic in nature.
RTP is inherently defined for group communications, originally assuming the availability of IP multicast. In today's practice, however, overlay-based conferencing dominates, typically using one or a few so-called conference bridges or servers to connect endpoints in a star or flat tree topology. Quite diverse conferencing topologies can be created using the basic elements of RTP mixers and translators as defined in RFC 3550.
An number of conferencing topologies are defined in [RFC5117] out of the which the following ones are the more common (and most likely in practice workable) ones:
1) RTP Translator (Relay) with Only Unicast Paths (RFC 5117, section 3.3)
2) RTP Mixer with Only Unicast Paths (RFC 5117, section 3.4)
3) Point to Multipoint Using a Video Switching MCU (RFC 5117, section 3.5)
4) Point to Multipoint Using Content Modifying MCUs (RFC 5117, section 3.6)
RTP protocol extensions to be used with conferencing are included because they are important in the context of centralized conferencing, where one RTP Mixer (Conference Focus) receives a participants media streams and distribute them to the other participants. These messages are defined in AVPF [RFC4585] or in "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)" [RFC5104].
The Full Intra Request is defined in Section 3.51 and 4.3.1 of [RFC5104]. It is used to have the mixer request from the currently distributed session participants a new Intra picture. This 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 this feedback message is supported.
The Picture Loss Indicator is defined in Section 6.3.1 of [RFC4585]. It is used by a receiver to tell the encoder that it lost the decoder context and would like to have it repaired somehow. This is semantically different from the the Full Intra Request above. It is RECOMMENDED that this feedback message is supported.
This feedback message is defined in Section 3.5.4 and 4.2.1 in [RFC5104]. This message and its notification message is used by a media receiver, to inform the sending party that there is a current limitation on the amount of bandwidth available to this receiver. This can be for various reasons, and can for example be used by an RTP mixer to limit the media sender being forwarded by the mixer (without doing media transcoding) to fit the bottlenecks existing towards the other session participants. It is RECOMMENDED that this feedback message is supported.
The RTP specification [RFC3550] provides a capability to extend the RTP header with in-band data, but the format and semantics of the extensions are poorly specified. Accordingly, if header extensions are to be used, it is REQUIRED that they be formatted and signalled according to the general mechanism of RTP header extensions defined in [RFC5285].
As noted in [RFC5285], the requirement from the RTP specification that header extensions are "designed so that the header extension may be ignored" [RFC3550] stands. To be specific, header extensions must only be used for data that can safely be ignored by the recipient without affecting interoperability, and must not be used when the presence of the extension has changed the form or nature of the rest of the packet in a way that is not compatible with the way the stream is signaled (e.g., as defined by the payload type). Valid examples might include metadata that is additional to the usual RTP information.
The RTP rapid synchronisation header extension is recommended, as discussed in Section 6.3.
Currently no other header extensions are recommended. But we do include a list of the available ones for consideration below:
Many RTP sessions require synchronisation between audio, video, and other content. This synchronisation is performed by receivers, using information contained in RTCP SR packets, as described in the RTP specification [RFC3550]. This basic mechanism can be slow, however, so it is RECOMMENDED that the rapid RTP synchronisation extensions described in [RFC6051] be implemented. The rapid synchronisation extensions use the general RTP header extension mechanism [RFC5285], which requires signalling, but are otherwise backwards compatible.
There are some tools that can robustify RTP flows against Packet loss and reduce the impact on media quality. However they all add extra bits compared to a non-robustified stream. These extra bits needs to be considered and the aggregate bit-rate needs to be rate controlled. Thus robustification might require a lower base encoding quality but has the potential to give that quality with fewer errors in it.
Support for RTP retransmission as defined by "RTP Retransmission Payload Format" [RFC4588] is RECOMMENDED.
The retransmission scheme in RTP allows flexible application of retransmissions. Only selected missing packets can be requested by the receiver. It also allows for the sender to prioritize between missing packets based on senders knowledge about their content. Compared to TCP, RTP retransmission also allows one to give up on a packet that despite retransmission(s) still has not been received within a time window.
Support of some type of FEC scheme to combat packet loss is beneficial, but is application dependent and also claimed to be mostly encumbered. For further discussion.
It is REQUIRED to have an RTP Rate Control mechanism using Media adaptation to ensure that the generated RTP flows are network friendly.
The biggest issue is that there are no standardized and ready to use mechanism that can simply be included in RTC-WEB. Thus there will be need for the IETF to produce such a specification. A potential starting point for defining a solution is "RTP with TCP Friendly Rate Control"[rtp-tfrc].
RTCP does contains a basic set of RTP flow monitoring points like packet loss and jitter. There exist a number of extensions that could be included in the set to be supported. However, in most cases which RTP monitoring that is needed depends on the application, which makes it difficult to select which to include when the set of applications is very large.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
RTP and its various extensions each have their own security considerations. These should be taken into account when considering the security properties of the complete suite. We currently don't think this suite creates any additional security issues or properties. The usage of SRTP will provide protection or mitigation against all the fundamental issues by offering confidentiality, integrity and partial source authentication. We don't discuss the key-management aspect of SRTP in this document, that needs to be done taking the RTC-WEB communication model into account.
In the context of RTC-WEB the actual security properties required from RTP are currently not fully understood. Until security goals and requirements are specified it will be difficult to determine what security features in addition to SRTP and a suitable key-management, if any, that are needed.
| [rtp-tfrc] | Gharai, L., "RTP with TCP Friendly Rate Control (draft-gharai-avtcore-rtp-tfrc-00)", March 2011. |
| [RFC2198] | Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. |