"RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Eve Schooler, Joerg Ott, Julian Chesterfield, 26-Mar-09. ( bytes)

This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. Ott et al. Internet Draft - Expires Sept 2009 [page 2] RTCP with Unicast Feedback

"How to Write an RTP Payload Format", Magnus Westerlund, 2-Mar-09. ( bytes)

This document contains information on how to best write an RTP payload format. Reading tips, design practices, and practical tips on how to quickly and with good results produce an RTP payload format specification. A template is also included with instructions that can be used when writing an RTP payload format.

"The use of AES-192 and AES-256 in Secure RTP", David McGrew, 6-Jul-09. ( bytes)

This memo describes the use of the Advanced Encryption Standard (AES) with 192 and 256 bit keys within the Secure RTP protocol. It defines Counter Mode encryption for SRTP and SRTCP and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256.

"Multiplexing RTP Data and Control Packets on a Single Port", Colin Perkins, Magnus Westerlund, 6-Aug-07. ( bytes)

This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions.

"RTP Payload Format for SVC Video", Stephan Wenger, Ye-Kui Wang, Thomas Schierl, Alex Eleftheriadis, 6-Mar-09. ( bytes)

This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. Table of Contents Status of this Memo...............................................1 Abstract..........................................................2

"RTP Payload Format for DV (IEC 61834) Video", Katsushi Kobayashi, Kazuhiro Mishima, Stephen Casner, Carsten Bormann, 23-Mar-09. ( bytes)

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document Obsoletes RFC 3189.

"RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 15-May-09. ( bytes)

This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech.

"Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows.", Xavier Marjou, Aurelien Sollaud, 23-Jun-09. ( bytes)

This document lists the different mechanisms that enable applications using Real-time Transport Protocol (RTP) to maintain their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents.

"Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", David McGrew, Eric Rescorla, 28-Feb-09. ( bytes)

This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for secure RTP (SRTP) and secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present.

"The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)", Seokung Yoon, Joongman Kim, Haeryong Park, Hyuncheol Jeong, Yoojae Won, 15-Jun-09. ( bytes)

This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).

"RTP Payload Format for H.264 RCDO Video", Tom Kristensen, 9-Mar-09. ( bytes)

This memo describes an RTP Payload format for the Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RTP Payload format is based on the description in RFC 3984.

"RTP Payload Format for SPIRIT IP-MR Speech Codec", Sergey Ikonin, 21-May-09. ( bytes)

This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and introduced redundancy for robustness against packet loss.

"Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 9-Mar-09. ( bytes)

The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptivity and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient.

"RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio", Frans Bont, Stefan Doehla, Malte Schmidt, Ralph Sperschneider, 28-Jul-09. ( bytes)

This memo describes extensions for the RTP payload format defined in RFC3640 for the transport of MPEG Surround multi-channel audio. Additional Media Type parameters are defined to signal backwards compatible transmission inside an MPEG-4 audio elementary stream. In addition a layered transmission scheme without using the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data.

"Post-Repair Loss RLE Report Block Type for RTCP XR", Ali Begen, Dong Hsu, Michael Lague, 16-Jun-09. ( bytes)

This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys the information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE Report, carries the information regarding the remaining lost packets after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE Report in the Session Description Protocol (SDP).

"Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus Westerlund, 13-Jul-09. ( bytes)

This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP) does not mandate a single media security mechanism.

"RTP Payload Format for H.264 Video", Ye-Kui Wang, Roni Even, Tom Kristensen, 1-May-09. ( bytes)

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multivew Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in section 18. Issues on backward compatibility to RFC 3984 are discussed in section 17.

"RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 28-Apr-09. ( bytes)

This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included.

"RTCP XR Report Block for Burst/Gap Loss metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Loss metrics for use in a range of RTP applications.

"RTCP XR Report Block for Burst/Gap Discard metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications.

"RTCP XR Report Block for Post-Repair Loss metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of a simple post-repair loss count metric for use in a range of RTP applications. It complements the pre-repair loss count metric "cumulative number of packets lost" provided by RFC3550.

"RTCP XR Report Block for Packet Delay Variation Metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications.

"RTCP XR Report Block for Measurement Identity", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block carrying parameters which identify a measurement, to which one or more other RTCP XR Report Blocks may refer.

"RTCP XR Report Block for Loss Concealment metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of Loss Concealment metrics primarily for audio applications of RTP.

"RTCP XR Report Block for Jitter Buffer Metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of Jitter Buffer metrics for a range of RTP applications.

"RTCP XR Report Block for Discard metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of a simple discard count metric for use in a range of RTP applications.

"RTCP XR Report Block for Delay metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of Delay metrics for use in a range of RTP applications.

"RTCP XR Report Block for Concealed Seconds metric Reporting", Geoff Hunt, Alan Clark, 15-May-09. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of Concealed Seconds metrics primarily for audio applications of RTP.

"Rapid Synchronisation of RTP Flows", Colin Perkins, Thomas Schierl, 13-Jul-09. ( bytes)

This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the presence of clock skew.

"RTP Payload format for GSM-HR", Xiaodong Duan, Shuaiyu Wang, Magnus Westerlund, Karl Hellwig, Ingemar Johansson, 15-Apr-09. ( bytes)

This document specifies the RTP payload format for packetization of the GSM Half-Rate speech codec.

"Unicast-Based Rapid Acquisition of Multicast RTP Sessions", Bill Ver Steeg, Ali Begen, Tom Van Caenegem, Zeev Vax, 16-Jun-09. ( bytes)

When an RTP receiver joins a primary multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition interval, size of the Reference Information as well as the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and may be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTCP protocol machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes/accompanies the primary multicast stream. This unicast RTP flow may be transmitted at a faster than natural rate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, the proposed method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem.

"AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, 6-Jul-09. ( bytes)

This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol.

Return to Internet-Draft directory.

Return to IETF home page.