|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
## AVTwg
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 12, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
## AVTwg
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
## AVTwg
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the AVT working group -- updated on October 23, 2007 --
is reported below.
|
|
|
|
The Audio/Video Transport (AVT)
working group was formed to specify a
protocol for real-time transmission of audio and video over unicast
and multicast UDP/IP. This is the Real-time Transport Protocol, RTP,
together with its associated profiles and payload formats. The
current aims of the working group are:
|
|
| - |
To review and revise existing payload formats to advance those which
are useful to Draft Standard, and to declare others as
Historic. Milestones will be established as a champion for each
payload format is identified.
|
| - |
To develop payload formats for new media codecs, and to document
best-current practices in payload format design. The group continues
to be precluded from work on codecs themselves because of overlap with
the other standards bodies, and because the IETF does not have the
ability to effectively review new codecs. An exception was made for
the freeware iLBC codec on a highly experimental basis, but acceptance
of new codec work is unexpected and subject to rechartering.
|
| - |
To complete the forward error correction work to update
RFC 2733 in
the form of the ULP payload format.
|
| - |
To extend RTP to work with Source-Specific Multicast sessions with
unicast feedback.
|
| - |
To provide a framing mechanism for RTP over TCP and TLS.
|
| - |
In collaboration with the MPLS and ROHC WGs, to develop a solution
for header compression of RTP across MPLS networks that avoid
decompression and compression at each MPLS node.
|
| - |
To develop a new RTP profile as the combination of the SRTP
profile and the Extended RTP Profile for RTCP-based Feedback
(RTP/SAVPF).
|
| - |
To maintain and enhance the SRTP Profile, with review and input from
the Security Area.
|
| - |
To develop a new RTP profile for usage of TFRC (RFC 3448) with RTP
over UDP to allow application developers to gain experience with TCP
friendly congestion control.
|
| - |
To develop a MIB for RTCP XR (RFC 3611).
|
| - |
To update the RTP MIB, including aligning it with
RFC 3550.
|
| - |
To clarify how RTP is used for media in conferencing with centralized
nodes performing relay, translation or mixing of media.
|
| - |
To develop the mechanisms needed for efficient control of media and
its encoding process in RTP based conferencing, both over multicast
and transport containing relays, translators and mixers. An example of
such a mechanism is a method to request a full intra coded frame of
video. This would be used to allow joining participants to receive
video immediately after joining instead of waiting for the next intra
coded frame. It also allows mixers to perform switching between media
sources without the need to re-encode the media.
|
| - |
To develop a solution for carrying media meta data, specifically SMPTE
timestamps, to enhance the media stream. Such transport may be done in
either RTP or RTCP depending on which is most suitable. The WG may
consider if a generalized mechanism should be developed to enable
future types of meta data to be easier to include.
|
| - |
To develop two new metric blocks for the RTCP XR (RFC 3611) framework
to provide information on the media quality experienced by the
receiver of RTP flows. One metrics block is for high resolution
measurements of audio and speech quality. A second one for providing
information on the quality of video. The timescale to complete this
second block and the included metrics are highly dependable on the
development of standardized subjective metrics for video quality. The
WG will consider what metrics that are available and if they should be
included or not. The metrics blocks shall not duplicate signaling
information anyway necessary for the establishment of the session.
|
| - |
To specify how the RFC 3550 requirement on RTCP senders to always
send compound packets can be relaxed to allow for non-compound
packets. The specification need to define under which criteria
non-compound RTCP packets may be sent while maintaining the
functionality that motivated the usage of compound RTCP packets
and keep the bandwidth within specified limits.
|
|
The longer term goals of the working group are to advance the SRTP
Profile, the Extended RTP Profile for RTCP-based Feedback, the
Compressed RTP framework, and the RTP MIB to Draft Standard.
The group has no plans to develop new RTP profiles beyond those listed
above, but will consider rechartering to produce profile level
extensions if appropriate.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
## AVTwg
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
avt-rfc2833biscas-05
RFC Ed Queue (05/08)
Jun 7, 2007
(26 p.)
[pdf(2)]
[html]
|
H. Schulzrinne
T. Taylor |
|
Definition of Events For Channel-Oriented Telephony Signalling |
|
This memo updates RFC 4733 to add event codes for telephony signals
used for channel-associated signalling when carried in the telephony
event RTP payload. It supersedes and adds to the original assignment
of event codes for this purpose in RFC 2833 section 3.14. As
documented in Appendix A of RFC 4733, certain of the RFC 2833 events
have been deprecated, because their specification was ambiguous,
erroneous or redundant. In fact, the degree of change from RFC 2833
section 3.14 is such that implementations of the present document
will be fully backward compatible with RFC 2833 implementations only
in the case of full ABCD-bit signalling. The positive benefits of
the present document are an expanded coverage of signalling systems
and a more carefully specified and documented coverage of signalling
systems covered by RFC 2833.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
## AVTwg
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
avt-rtcpssm-17
AD Evaluation
Jan 7, 2008
(59 p.)
[pdf(2)]
[html]
|
J. Ott
J. Chesterfield
E. Schooler |
|
RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
avt-rtp-atrac-
family-16
Publication Requested
Apr 7, 2008
(36 p.)
[pdf(2)]
[html]
|
M. Hatanaka
J. Matsumoto |
|
RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
avt-rtp-hdrext-15
In Last Call
Mar 11, 2008
(24 p.)
[pdf(2)]
[html]
|
D. Singer
H. Desineni |
|
A general mechanism for RTP Header Extensions |
|
This document provides a general mechanism to use the header-extension
feature of RTP (the Real Time Transport Protocol). It
provides the option to use a small number of small extensions in each
RTP packet, where the universe of possible extensions is large and
registration is de-centralized. The actual extensions in use in a
session are signaled in the setup information for that session.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
avt-rtp-jpeg2000-19
Waiting for
AD Go-Ahead
Apr 24, 2008
(37 p.)
[pdf(2)]
[html]
|
S. Futemma
A. Leung
E. Itakura |
|
RTP Payload Format for JPEG 2000 Video Streams |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
avt-rtp-
jpeg2000-beam-10
Waiting for
AD Go-Ahead
Apr 24, 2008
(33 p.)
[pdf(2)]
[html]
|
A. Leung
S. Futemma
E. Itakura |
|
Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery |
This memo describes extended uses for payload header in RFC document:
"RTP Payload Format for JPEG 2000 Video Streams." 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.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
avt-rtp-vorbis-09
IESG Evaluation::
Revised ID Needed
Feb 17, 2008
(25 p.)
[pdf(2)]
[html]
|
L. Barbato |
|
RTP Payload Format for Vorbis Encoded Audio |
This document describes an RTP payload format for transporting Vorbis
encoded audio. It details the RTP encapsulation mechanism for raw
Vorbis data and details the delivery mechanisms for the decoder
probability model, referred to as a codebook and other setup
information.
Also included within this memo are media type registrations, and the
details necessary for the use of Vorbis with the Session Description
Protocol (SDP).
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
## AVTwg
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
avt-forward-
shifted-red-01
ID Exists
Mar 17, 2008
(13 p.)
[pdf(2)]
[html]
|
Q. Xie
J. Schumacher |
|
Forward-shifted RTP Redundancy Payload Support |
|
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).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
avt-rfc4695-bis-03
ID Exists
Feb 13, 2008
(183 p.)
[pdf(2)]
[html]
|
J. Lazzaro
J. Wawrzynek |
|
RTP Payload Format for MIDI |
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.
This I-D is a modified version of RFC 4695.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
avt-rtp-howto-03
ID Exists
Feb 25, 2008
(54 p.)
[pdf(2)]
[html]
|
M. Westerlund |
|
How to Write an RTP Payload Format |
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.
This document extends and updates the information that are available
in RFC 2736. Since this RFC was written further experience has been
gained on the design and specification of RTP payload format.
Several new RTP profiles, and robustness tools has also been defined,
which needs to be considered.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
