|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3550
07/2003
(104 p.)
[html]
[pdf(2)] |
H. Schulzrinne
S. Casner
R. Frederick
V. Jacobson |
AVT |
| RTP: A Transport Protocol for
Real-Time Applications |
|
This memorandum describes RTP, the real-time transport protocol. RTP
provides end-to-end network transport functions suitable for
applications transmitting real-time data, such as audio, video or
simulation data, over multicast or unicast network services. RTP
does not address resource reservation and does not guarantee
quality-of-service for real-time services. The data transport is
augmented by a control protocol (RTCP) to allow monitoring of the
data delivery in a manner scalable to large multicast networks, and
to provide minimal control and identification functionality. RTP and
RTCP are designed to be independent of the underlying transport and
network layers. The protocol supports the use of RTP-level
translators and mixers.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3551
07/2003
(44 p.)
[html]
[pdf(2)] |
H. Schulzrinne
S. Casner |
AVT |
| RTP Profile for Audio and Video
Conferences with Minimal Control |
This document describes a profile called "RTP/AVP" for the use of the
real-time transport protocol (RTP), version 2, and the associated
control protocol, RTCP, within audio and video multiparticipant
conferences with minimal control. It provides interpretations of
generic fields within the RTP specification suitable for audio and
video conferences. In particular, this document defines a set of
default mappings from payload type numbers to encodings.
This document also describes how audio and video data may be carried
within RTP. It defines a set of standard encodings and their names
when used within RTP. The descriptions provide pointers to reference
implementations and the detailed standards. This document is meant
as an aid for implementors of audio, video and other real-time
multimedia applications.
|
|
|
| |
| Top |
Status: | Standard (STD0065) | Obsoletes: RFC 1890 |
|
|
|
|
|
|
|
|
| | | |
RFC2736
12/1999
(10 p.)
[html]
[pdf(2)] |
M. Handley
C. Perkins |
AVT |
|
Guidelines for Writers of RTP Payload Format Specifications |
This document provides general guidelines aimed at assisting the
authors of RTP Payload Format specifications in deciding on good
formats. These guidelines attempt to capture some of the experience
gained with RTP as it evolved during its development.
The principles outlined in this document are applicable to almost all
data types, but are framed in examples of audio and video codecs for
clarity.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5117
01/2008
(21 p.)
[html]
[pdf(2)] |
M. Westerlund
S. Wenger |
AVT |
|
RTP Topologies |
|
This document discusses multi-endpoint topologies used in Real-time
Transport Protocol (RTP)-based environments. In particular,
centralized topologies commonly employed in the video conferencing
industry are mapped to the RTP terminology.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## RTCP
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3556
07/2003
(8 p.)
[html]
[pdf(2)] |
S. Casner |
AVT |
|
SDP Bandwidth Modifiers for RTCP Bandwidth |
|
This document defines an extension to the Session Description
Protocol (SDP) to specify two additional modifiers for the bandwidth
attribute. These modifiers may be used to specify the bandwidth
allowed for RTP Control Protocol (RTCP) packets in a Real-time
Transport Protocol (RTP) session.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC3611
11/2003
(55 p.)
[html]
[pdf(2)] |
T. Friedman
R. Caceres
A. Clark |
AVT |
|
RTP Control Protocol Extended Reports (RTCP XR) |
|
This document defines the Extended Report (XR) packet type for the
RTP Control Protocol (RTCP), and defines how the use of XR packets
can be signaled by an application if it employs the Session
Description Protocol (SDP). XR packets are composed of report
blocks, and seven block types are defined here. The purpose of the
extended reporting format is to convey information that supplements
the six statistics that are contained in the report blocks used by
RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some
applications, such as multicast inference of network characteristics
(MINC) or voice over IP (VoIP) monitoring, require other and more
detailed statistics. In addition to the block types defined here,
additional block types may be defined in the future by adhering to
the framework that this document provides.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4585
07/2006
(51 p.)
[html]
[pdf(2)] |
J. Ott
S. Wenger
N. Sato
C. Burmeister
J. Rey |
AVT |
|
Extended RTP Profile for
RTCP-Based Feedback (RTP/AVPF) |
|
Real-time media streams that use RTP are, to some degree, resilient
against packet losses. Receivers may use the base mechanisms of the
Real-time Transport Control Protocol (RTCP) to report packet
reception statistics and thus allow a sender to adapt its
transmission behavior in the mid-term. This is the sole means for
feedback and feedback-based error repair (besides a few codec-specific
mechanisms). This document defines an extension to the
Audio-visual Profile (AVP) that enables receivers to provide,
statistically, more immediate feedback to the senders and thus allows
for short-term adaptation and efficient feedback-based repair
mechanisms to be implemented. This early feedback profile (AVPF)
maintains the AVP bandwidth constraints for RTCP and preserves
scalability to large groups.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4586
07/2006
(28 p.)
[html]
[pdf(2)] |
C. Burmeister
R. Hakenberg
A. Miyazaki
J. Ott
N. Sato
S. Fukunaga |
AVT |
|
Extended RTP Profile for RTCP-Based Feedback:
Results of the Timing Rule Simulations |
|
This document describes the results achieved when simulating the
timing rules of the Extended RTP Profile for Real-time Transport
Control Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and
multicast topologies are considered as well as several protocol and
environment configurations. The results show that the timing rules
result in better performance regarding feedback delay and still
preserve the well-accepted RTP rules regarding allowed bit rates for
control traffic.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5093
12/2007
(8 p.)
[html]
[pdf(2)] |
G. Hunt |
AVT |
|
BT's eXtended Network Quality RTP Control Protocol Extended Reports
(RTCP XR XNQ) |
|
This document describes an RTCP XR report block, which reports packet
transport parameters. The report block was developed by BT for pre-
standards use in BT's next-generation network. This document has
been produced to describe the report block in sufficient detail to
register the block type with IANA in accordance with the
Specification Required policy of RFC 3611. This specification does
not standardise the new report block for use outside BT's network.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5104
02/2008
(64 p.)
[html]
[pdf(2)] |
S. Wenger
U. Chandra
M. Westerlund
B. Burman |
AVT |
|
Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) |
This document specifies a few extensions to the messages defined in
the Audio-Visual Profile with Feedback (AVPF). They are helpful
primarily in conversational multimedia scenarios where centralized
multipoint functionalities are in use. However, some are also usable
in smaller multicast environments and point-to-point calls.
The extensions discussed are messages related to the ITU-T Rec. H.271
Video Back Channel, Full Intra Request, Temporary Maximum Media
Stream Bit Rate, and Temporal-Spatial Trade-off.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
## SRTP
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3711
03/2004
(56 p.)
[html]
[pdf(2)] |
M. Baugher
D. McGrew
M. Naslund
E. Carrara
K. Norrman |
AVT |
|
The Secure Real-time Transport Protocol (SRTP) |
|
This document describes the Secure Real-time Transport Protocol
(SRTP), a profile of the Real-time Transport Protocol (RTP), which
can provide confidentiality, message authentication, and replay
protection to the RTP traffic and to the control traffic for RTP, the
Real-time Transport Control Protocol (RTCP).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
## CRTP
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC3545
07/2003
(22 p.)
[html]
[pdf(2)] |
T. Koren
S. Casner
J. Geevarghese
B. Thompson
P. Ruddy |
AVT |
|
Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering |
|
This document describes a header compression scheme for point to
point links with packet loss and long delays. It is based on
Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header
compression described in RFC2508. CRTP does not perform well on
such links: packet loss results in context corruption and due to the
long delay, many more packets are discarded before the context is
repaired. To correct the behavior of CRTP over such links, a few
extensions to the protocol are specified here. The extensions aim to
reduce context corruption by changing the way the compressor updates
the context at the decompressor: updates are repeated and include
updates to full and differential context parameters. With these
extensions, CRTP performs well over links with packet loss, packet
reordering and long delays.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4170
11/2005
(24 p.)
[html]
[pdf(2)] |
B. Thompson
T. Koren
D. Wing |
AVT |
|
Tunneling Multiplexed Compressed RTP (TCRTP) |
|
This document describes a method to improve the bandwidth utilization
of RTP streams over network paths that carry multiple Real-time
Transport Protocol (RTP) streams in parallel between two endpoints,
as in voice trunking. The method combines standard protocols that
provide compression, multiplexing, and tunneling over a network path
for the purpose of reducing the bandwidth used when multiple RTP
streams are carried over that path.
|
|
|
| |
| Up |
Status: | Best Current Practice (BCP: 110) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
## Registration
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4855
02/2007
(11 p.)
[html]
[pdf(2)] |
S. Casner |
AVT |
|
Media Type Registration of RTP Payload Formats |
|
This document specifies the procedure to register RTP payload formats
as audio, video, or other media subtype names. This is useful in a
text-based format description or control protocol to identify the
type of an RTP transmission.
|
|
|
| |
| Up |
Status: | Proposed Standard |
Obsoletes: RFC 3555 |
|
|
|
|
|
|
|
|
| | | |
RFC4856
03/2007
(29 p.)
[html]
[pdf(2)] |
S. Casner |
AVT |
|
Media Type Registration of Payload Formats in the
RTP Profile for Audio and Video Conferences |
This document specifies media type registrations for the RTP payload
formats defined in the RTP Profile for Audio and Video Conferences.
Some of these may also be used for transfer modes other than RTP.
This document updates the media type registrations listed below to
conform to the revised registration format specified in RFC4288 and
RFC4855. Some media type registrations
contained in RFC3555 are omitted from this document; the existing
registrations for those types continue to be valid until updated by
other RFCs. There are no new registrations contained here.
| | | |
audio/DVI4
audio/G722
audio/G723
audio/G726-16
audio/G726-24
audio/G726-32
audio/G726-40
|
audio/G728
audio/G729
audio/G729D
audio/G729E
audio/GSM
audio/GSM-EFR
audio/L8
|
audio/L16
audio/LPC
audio/PCMA
audio/PCMU
audio/VDVI
video/nv
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
Obsoletes: RFC 3555 |
|
|
|
|
|
|
|
|
| | | |
RFC4573
07/2006
(7 p.)
[html]
[pdf(2)] |
R. Even
A. Lochbaum |
AVT |
|
MIME Type Registration for RTP Payload Format for H.224 |
|
In conversational video applications, far-end camera control protocol
is used by participants to control the remote camera. The protocol
that is commonly used is ITU H.281 over H.224. The document
registers the "application/H224" media type. It defines the syntax and the
semantics of the Session Description Protocol (SDP) parameters needed
to support far-end camera control protocol using H.224.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | | |
RFC4612
08/2006
(8 p.)
[html]
[pdf(2)] |
P. Jones
H. Tamura |
AVT |
|
Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration |
ITU-T Recommendation T.38 defines the Internet Facsimile Protocol
(IFP) for carriage of facsimile data over IP networks. As one
option, IFP packets may be carried within an RTP stream, either
as the only content within the media stream or switched with other
audio payload types.
This memo provides rationale for using RTP as a transport for fax
signaling and specifies the "audio/t38" MIME type associated with said signaling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
## MIB
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
## Framing
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4247
11/2005
(11 p.)
[html]
[pdf(2)] |
J. Ash
B. Goode
J. Hand
R. Zhang |
AVT |
|
Requirements for Header Compression over MPLS |
|
Voice over IP (VoIP) typically uses the encapsulation
voice/RTP/UDP/IP. When MPLS labels are added, this becomes
voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is
typically 48 bytes, while the voice payload is often no more than 30
bytes, for example. Header compression can significantly reduce the
overhead through various compression mechanisms, such as enhanced
compressed RTP (ECRTP) and robust header compression (ROHC). We
consider using MPLS to route compressed packets over an MPLS Label
Switched Path (LSP) without compression/decompression cycles at each
router. This approach can increase the bandwidth efficiency as well
as processing scalability of the maximum number of simultaneous flows
that use header compression at each router. In this document, we
give a problem statement, goals and requirements, and an example
scenario.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4901
06/2007
(34 p.)
[html]
[pdf(2)] |
J. Ash
J. Hand
A. Malis |
AVT |
|
Protocol Extensions for Header Compression over MPLS |
|
This specification defines how to use Multi-Protocol Label Switching
(MPLS) to route Header-Compressed (HC) packets over an MPLS label
switched path. HC can significantly reduce packet-header overhead
and, in combination with MPLS, can also increases bandwidth
efficiency and processing scalability in terms of the maximum number
of simultaneous compressed flows that use HC at each router). Here
we define how MPLS pseudowires are used to transport the HC context
and control messages between the ingress and egress MPLS label
switching routers. This is defined for a specific set of existing HC
mechanisms that might be used, for example, to support voice over IP.
This specification also describes extension mechanisms to allow
support for future, as yet to be defined, HC protocols. In this
specification, each HC protocol operates independently over a single
pseudowire instance, very much as it would over a single point-to-point
link.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
## Sampling
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC2762
02/2000
(12 p.)
[html]
[pdf(2)] |
J. Rosenberg
H. Schulzrinne |
AVT |
|
Sampling of the Group Membership in RTP |
|
In large multicast groups, the size of the group membership table
maintained by RTP (Real Time Transport Protocol) participants may
become unwieldy, particularly for embedded devices with limited
memory and processing power. This document discusses mechanisms for
sampling of this group membership table in order to reduce the memory
requirements. Several mechanisms are proposed, and the performance of
each is considered.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
## Repair
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC2354
06/1998
(12 p.)
[html]
[pdf(2)] |
C. Perkins
O. Hodson |
AVT |
|
Options for Repair of Streaming Media |
|
This document summarizes a range of possible techniques for the
repair of continuous media streams subject to packet loss. The
techniques discussed include redundant transmission, retransmission,
interleaving and forward error correction. The range of
applicability of these techniques is noted, together with the
protocol requirements and dependencies.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4588
07/2006
(35 p.)
[html]
[pdf(2)] |
J. Rey
D. Leon
A. Miyazaki
V. Varsa
R. Hakenberg |
AVT |
|
RTP Retransmission Payload Format |
|
RTP retransmission is an effective packet loss recovery technique for
real-time applications with relaxed delay bounds. This document
describes an RTP payload format for performing retransmissions.
Retransmitted RTP packets are sent in a separate stream from the
original RTP stream. It is assumed that feedback from receivers to
senders is available. In particular, it is assumed that Real-time
Transport Control Protocol (RTCP) feedback as defined in the extended
RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available
in this memo.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
## Test
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3158
08/2001
(22 p.)
[html]
[pdf(2)] |
C. Perkins
J. Rosenberg
H. Schulzrinne |
AVT |
|
RTP Testing Strategies |
This memo describes a possible testing strategy for RTP (real-time
transport protocol) implementations.
This memo describes a possible testing strategy for RTP
implementations. The tests are intended to help demonstrate
interoperability of multiple implementations, and to illustrate
common implementation errors. They are not intended to be an
exhaustive set of tests and passing these tests does not necessarily
imply conformance to the complete RTP specification.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
## FEC
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC5109
12/2007
(44 p.)
[html]
[pdf(2)] |
A. Li |
AVT |
|
RTP Payload Format for Generic Forward Error Correction |
|
This document specifies a payload format for generic Forward Error
Correction (FEC) for media data encapsulated in RTP. It is based on
the exclusive-or (parity) operation. The payload format described in
this document allows end systems to apply protection using various
protection lengths and levels, in addition to using various
protection group sizes to adapt to different media and channel
characteristics. It enables complete recovery of the protected
packets or partial recovery of the critical parts of the payload
depending on the packet loss situation. This scheme is completely
compatible with non-FEC-capable hosts, so the receivers in a
multicast group that do not implement FEC can still work by simply
ignoring the protection data. This specification obsoletes RFC 2733
and RFC 3009. The FEC specified in this document is not backward
compatible with RFC 2733 and RFC 3009.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
## G.722
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3047
01/2001
(8 p.)
[html]
[pdf(2)] |
P. Luthi |
AVT |
|
RTP Payload Format for ITU-T Recommendation G.722.1 |
International Telecommunication Union (ITU-T) Recommendation G.722.1
is a wide-band audio codec, which operates at one of two selectable
bit rates, 24kbit/s or 32kbit/s. This document describes the payload
format for including G.722.1 generated bit streams within an RTP
packet. Also included here are the necessary details for the use of
G.722.1 with MIME and SDP.
The "audio/G7221" media type has been registered by the IANA.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
## G.729
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4749
10/2006
(13 p.)
[html]
[pdf(2)] |
A. Sollaud |
AVT |
|
RTP Payload Format for the G.729.1 Audio Codec |
This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for the International Telecommunication Union
(ITU-T) G.729.1 audio codec.
G.729.1 is an 8-32 kbps scalable wideband (50-7000 Hz) speech and
audio coding algorithm interoperable with G.729, G.729 Annex A, and
G.729 Annex B. It provides a standardized solution for packetized
voice applications that allows a smooth transition from narrowband to
wideband telephony.
The "audio/G7291" media type has been registered by the IANA.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
## Comfort Noise
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## |
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3389
09/2002
(8 p.)
[html]
[pdf(2)] |
R. Zopf |
AVT |
|
RTP Payload for Comfort Noise (CN) |
This document describes a Real-time Transport Protocol (RTP) payload
format for transporting comfort noise (CN). The CN payload type is
primarily for use with audio codecs that do not support comfort noise
as part of the codec itself such as ITU-T Recommendations G.711,
G.726, G.727, G.728, and G.722.
The "audio/CN" media type has been registered by the IANA.
|
|
|
| |
| Up |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
