"RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Joerg Ott, 7-Jan-08. ( 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 sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either 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 July 2008 [page 1] RTCP with Unicast Feedback

"RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family", Jun Matsumoto, Mitsuyuki Hatanaka, 4-Sep-08. ( bytes)

This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming.

"Associating Time-codes with RTP streams", David Singer, 3-Nov-08. ( bytes)

This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams, in a way that is independent of the RTP payload format of the media stream itself.

"RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, Roni Even, 22-Aug-08. ( bytes)

International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describes the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec.

"RTP Payload Format for the Speex Codec", Greg Herlein, Jean-Marc Valin, Alfred Heggestad, Aymeric Moizard, 16-Feb-08. ( bytes)

Speex is an open-source voice codec suitable for use in Voice over IP (VoIP) type applications. This document describes the payload format for Speex generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP).Editors Note All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published.

"How to Write an RTP Payload Format", Magnus Westerlund, 11-Sep-08. ( 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.

"Transmission Time offsets in RTP streams", David Singer, HariKishan Desineni, 11-Mar-08. ( bytes)

This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times.

"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, 3-Nov-08. ( 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. For single-session transmission the packetization modes of [I-D.ietf-avt-rtp- rfc3984bis] are used. For multi-session transmission four different modes are defined in this memo. The modes differ depending on whether the SVC data are allowed to be interleaved, i.e., to be transmitted in an order different than the intended decoding order, and they also differ in the mechanisms provided in order to recover the correct decoding order of the NAL units across the multiple RTP sessions. Specifically, decoding order recovery is performed using either timestamp alignment or Cross-Session Decoding Order Numbers (CS-DON), although in one of the modes both schemes are used in order to allow receivers to use their preferred method. The multi- session transmission modes use the packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] as each individual session still uses a packetization mode defined in [I-D.ietf-avt-rtp-rfc3984bis]. The packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] are slightly extended such that the three new NAL unit types defined in this memo can be included in the RTP packet streams. 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 Copyright Notice..................................................1 Abstract..........................................................2

"RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, Intellectual Property, 6-Aug-08. ( bytes)

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio.

"RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 25-Feb-08. ( 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, 2-Oct-08. ( 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, 29-Oct-08. ( 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.

"Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, 7-Oct-08. ( bytes)

This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media).

"The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)", Intellectual Property, 17-Nov-08. ( 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).

"Support for Reduced-Size RTCP, Opportunities and Consequences", Ingemar Johansson, Magnus Westerlund, 18-Nov-08. ( bytes)

This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC3550 are removed or changed. Based on that analysis this memo defines certain changes to the rules to allow feedback messages to be sent as reduced-size RTCP packets under certain conditions when using the RTP AVPF profile (RFC 4585). This document updates [RFC3550], [RFC3711] and [RFC4585].

"RTP Payload Format for H.264 RCDO Video", Tom Kristensen, 22-May-08. ( 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.

"G.729.1 RTP Payload Format update: DTX support", Aurelien Sollaud, 26-Sep-08. ( bytes)

This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format.

"RTP Payload Format for ITU-T Recommendation G.711.1", Aurelien Sollaud, 28-Apr-08. ( bytes)

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.711.1 audio codec. Two media type registrations are also included.

"Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 7-Jul-08. ( 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, 20-Oct-08. ( 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.

"RTP Payload format for G.719", Magnus Westerlund, Ingemar Johansson, 17-Nov-08. ( bytes)

This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving.

"Post-Repair Loss RLE Report Block Type for RTCP XR", Ali Begen, Dong Hsu, Michael Lague, 27-Oct-08. ( 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, 4-Nov-08. ( 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, 3-Nov-08. ( 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 intends to obsolete RFC 3984. Changes from RFC 3984 are summarized in section 17. Issues on backward compatibility to RFC 3984 are discussed in section 16.

"RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 23-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( 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, 27-Oct-08. ( bytes)

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

"RTCP XR Report Block for QoE Metrics Reporting", Alan Clark, Geoff Hunt, 27-Oct-08. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of QoE metrics for use in voice, audio and video services.

"RTCP XR Report Block for Signal Level Metrics Reporting", Alan Clark, Geoff Hunt, 27-Oct-08. ( bytes)

This document defines an RTCP XR Report Block that allows the reporting of metrics related to signal levels for use in voice, audio and video services.

Return to Internet-Draft directory.

Return to IETF home page.