"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 JPEG 2000 Video Streams", Satoshi Futemma, 30-Jun-08. ( bytes)

This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, otherwise better known as: JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways. JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images.

"RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family", Jun Matsumoto, Mitsuyuki Hatanaka, 14-Aug-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.

"Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery", Andrew Leung, 30-Jun-08. ( bytes)

This memo describes extended uses for payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC XXXY. For better support of JPEG 2000 features such as scalability and main header recovery. This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams." That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and SDP marker signaling for implementations of this document. -- RFC-Editor Note: The authors ask the RFC Editors to replace all instances of RFC XXXY with the RFC number assigned when draft-ietf-avt-rtp-jpeg2000-20 [JP2RTP] is published as an RFC. At that time, please remove the note.

"Associating Time-codes with RTP streams", David Singer, 24-Jun-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-Jul-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, 14-Jul-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 streams the packetization modes of RFC 3984 are used, whereas for multi-session streams four different packetization modes are defined in this memo. The multi-session packetization modes extend the packetization modes defined in RFC 3984. The payload format is backwards compatible to RFC 3984, and 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 DV (IEC 61834) Video", Katsushi Kobayashi, Kazuhiro Mishima, Stephen Casner, Carsten Bormann, 24-Mar-08. ( 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, 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, 8-Apr-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, 26-Aug-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, Joe Schumacher, 17-Mar-08. ( bytes)

This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data is 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, 14-Jul-08. ( bytes)

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

"Support for Reduced-Size RTCP, Opportunities and Consequences", Ingemar Johansson, Magnus Westerlund, 7-Jul-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).

"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, 15-May-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.

"RTP Payload Format for SPIRIT IP-MR Speech Codec Software", Andrey Setsko, 4-Apr-08. ( 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, introduced redundancy for robustness against packet loss, and payload format extension for future versions compatibility.

"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, 7-Jul-08. ( bytes)

This memo describes extensions for the RTP payload format defined in RFC3640 for the transport of MPEG Surround multi-channel audio. Additional MIME 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, 7-Jul-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, 6-Aug-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 error-repair techniques are applied. By comparing the RTP packet receipts/losses before and after the error repair is completed, one can determine the effectiveness of the error-repair techniques 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, 29-Jul-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.

Return to Internet-Draft directory.

Return to IETF home page.