As per Relevance of the word identifier, we have this rfc below:
Network Working Group Audio-Video Transport Working
Request for Comments: 1889 H.
Category: Standards Track GMD
S.
Precept Software, Inc
R.
Xerox Palo Alto Research
V.
Lawrence Berkeley National
January 1996
RTP: A Transport Protocol for Real-Time
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memorandum describes RTP, the real-time transport protocol.
provides end-to-end network transport functions suitable
applications transmitting real-time data, such as audio, video
simulation data, over multicast or unicast network services. RTP
not address resource reservation and does not guarantee quality-of
service for real-time services. The data transport is augmented by
control protocol (RTCP) to allow monitoring of the data delivery in
manner scalable to large multicast networks, and to provide
control and identification functionality. RTP and RTCP are
to be independent of the underlying transport and network layers.
protocol supports the use of RTP-level translators and mixers
Table of
1. Introduction ........................................ 3
2. RTP Use Scenarios ................................... 5
2.1 Simple Multicast Audio Conference ................... 5
2.2 Audio and Video Conference .......................... 6
2.3 Mixers and Translators .............................. 6
3. Definitions ......................................... 7
4. Byte Order, Alignment, and Time Format .............. 9
5. RTP Data Transfer Protocol .......................... 10
5.1 RTP Fixed Header Fields ............................. 10
5.2 Multiplexing RTP Sessions ........................... 13
Schulzrinne, et al Standards Track [Page 1]
RFC 1889 RTP January 1996
5.3 Profile-Specific Modifications to the RTP Header..... 14
5.3.1 RTP Header Extension ................................ 14
6. RTP Control Protocol -- RTCP ........................ 15
6.1 RTCP Packet Format .................................. 17
6.2 RTCP Transmission Interval .......................... 19
6.2.1 Maintaining the number of session members ........... 21
6.2.2 Allocation of source description bandwidth .......... 21
6.3 Sender and Receiver Reports ......................... 22
6.3.1 SR: Sender report RTCP packet ....................... 23
6.3.2 RR: Receiver report RTCP packet ..................... 28
6.3.3 Extending the sender and receiver reports ........... 29
6.3.4 Analyzing sender and receiver reports ............... 29
6.4 SDES: Source description RTCP packet ................ 31
6.4.1 CNAME: Canonical end-point identifier SDES item ..... 32
6.4.2 NAME: User name SDES item ........................... 34
6.4.3 EMAIL: Electronic mail address SDES item ............ 34
6.4.4 PHONE: Phone number SDES item ....................... 34
6.4.5 LOC: Geographic user location SDES item ............. 35
6.4.6 TOOL: Application or tool name SDES item ............ 35
6.4.7 NOTE: Notice/status SDES item ....................... 35
6.4.8 PRIV: Private extensions SDES item .................. 36
6.5 BYE: Goodbye RTCP packet ............................ 37
6.6 APP: Application-defined RTCP packet ................ 38
7. RTP Translators and Mixers .......................... 39
7.1 General Description ................................. 39
7.2 RTCP Processing in Translators ...................... 41
7.3 RTCP Processing in Mixers ........................... 43
7.4 Cascaded Mixers ..................................... 44
8. SSRC Identifier Allocation and Use .................. 44
8.1 Probability of Collision ............................ 44
8.2 Collision Resolution and Loop Detection ............. 45
9. Security ............................................ 49
9.1 Confidentiality ..................................... 49
9.2 Authentication and Message Integrity ................ 50
10. RTP over Network and Transport Protocols ............ 51
11. Summary of Protocol Constants ....................... 51
11.1 RTCP packet types ................................... 52
11.2 SDES types .......................................... 52
12. RTP Profiles and Payload Format Specifications ...... 53
A. Algorithms .......................................... 56
A.1 RTP Data Header Validity Checks ..................... 59
A.2 RTCP Header Validity Checks ......................... 63
A.3 Determining the Number of RTP Packets Expected
Lost ................................................ 63
A.4 Generating SDES RTCP Packets ........................ 64
A.5 Parsing RTCP SDES Packets ........................... 65
A.6 Generating a Random 32-bit Identifier ............... 66
A.7 Computing the RTCP Transmission Interval ............ 68
Schulzrinne, et al Standards Track [Page 2]
RFC 1889 RTP January 1996
A.8 Estimating the Interarrival Jitter .................. 71
B. Security Considerations ............................. 72
C. Addresses of Authors ................................ 72
D. Bibliography ........................................ 73
1.
This memorandum specifies the real-time transport protocol (RTP),
which provides end-to-end delivery services for data with real-
characteristics, such as interactive audio and video. Those
include payload type identification, sequence numbering,
and delivery monitoring. Applications typically run RTP on top of
to make use of its multiplexing and checksum services; both
contribute parts of the transport protocol functionality. However
RTP may be used with other suitable underlying network or
protocols (see Section 10). RTP supports data transfer to
destinations using multicast distribution if provided by
underlying network
Note that RTP itself does not provide any mechanism to ensure
delivery or provide other quality-of-service guarantees, but
on lower-layer services to do so. It does not guarantee delivery
prevent out-of-order delivery, nor does it assume that the
network is reliable and delivers packets in sequence. The
numbers included in RTP allow the receiver to reconstruct
sender's packet sequence, but sequence numbers might also be used
determine the proper location of a packet, for example in
decoding, without necessarily decoding packets in sequence
While RTP is primarily designed to satisfy the needs of multi
participant multimedia conferences, it is not limited to
particular application. Storage of continuous data,
distributed simulation, active badge, and control and
applications may also find RTP applicable
This document defines RTP, consisting of two closely-linked parts
o the real-time transport protocol (RTP), to carry data that
real-time properties
o the RTP control protocol (RTCP), to monitor the quality
service and to convey information about the participants in
on-going session. The latter aspect of RTCP may be
for "loosely controlled" sessions, i.e., where there is
explicit membership control and set-up, but it is
necessarily intended to support all of an application's
communication requirements. This functionality may be fully
partially subsumed by a separate session control protocol
Schulzrinne, et al Standards Track [Page 3]
RFC 1889 RTP January 1996
which is beyond the scope of this document
RTP represents a new style of protocol following the principles
application level framing and integrated layer processing proposed
Clark and Tennenhouse [1]. That is, RTP is intended to be
to provide the information required by a particular application
will often be integrated into the application processing rather
being implemented as a separate layer. RTP is a protocol
that is deliberately not complete. This document specifies
functions expected to be common across all the applications for
RTP would be appropriate. Unlike conventional protocols in
additional functions might be accommodated by making the
more general or by adding an option mechanism that would
parsing, RTP is intended to be tailored through modifications and/
additions to the headers as needed. Examples are given in
5.3 and 6.3.3.
Therefore, in addition to this document, a complete specification
RTP for a particular application will require one or more
documents (see Section 12):
o a profile specification document, which defines a set
payload type codes and their mapping to payload formats (e.g.,
media encodings). A profile may also define extensions
modifications to RTP that are specific to a particular class
applications. Typically an application will operate under
one profile. A profile for audio and video data may be found
the companion RFC TBD
o payload format specification documents, which define how
particular payload, such as an audio or video encoding, is
be carried in RTP
A discussion of real-time services and algorithms for
implementation as well as background discussion on some of the
design decisions can be found in [2].
Several RTP applications, both experimental and commercial,
already been implemented from draft specifications.
applications include audio and video tools along with
tools such as traffic monitors. Users of these tools number in
thousands. However, the current Internet cannot yet support the
potential demand for real-time services. High-bandwidth
using RTP, such as video, can potentially seriously degrade
quality of service of other network services. Thus,
should take appropriate precautions to limit accidental
usage. Application documentation should clearly outline
limitations and possible operational impact of high-bandwidth real
Schulzrinne, et al Standards Track [Page 4]
RFC 1889 RTP January 1996
time services on the Internet and other network services
2. RTP Use
The following sections describe some aspects of the use of RTP.
examples were chosen to illustrate the basic operation
applications using RTP, not to limit what RTP may be used for.
these examples, RTP is carried on top of IP and UDP, and follows
conventions established by the profile for audio and video
in the companion Internet-Draft draft-ietf-avt-
2.1 Simple Multicast Audio
A working group of the IETF meets to discuss the latest
draft, using the IP multicast services of the Internet for
communications. Through some allocation mechanism the working
chair obtains a multicast group address and pair of ports. One
is used for audio data, and the other is used for control (RTCP
packets. This address and port information is distributed to
intended participants. If privacy is desired, the data and
packets may be encrypted as specified in Section 9.1, in which
an encryption key must also be generated and distributed. The
details of these allocation and distribution mechanisms are
the scope of RTP
The audio conferencing application used by each
participant sends audio data in small chunks of, say, 20 ms duration
Each chunk of audio data is preceded by an RTP header; RTP header
data are in turn contained in a UDP packet. The RTP header
what type of audio encoding (such as PCM, ADPCM or LPC) is
in each packet so that senders can change the encoding during
conference, for example, to accommodate a new participant that
connected through a low-bandwidth link or react to indications
network congestion
The Internet, like other packet networks, occasionally loses
reorders packets and delays them by variable amounts of time. To
with these impairments, the RTP header contains timing
and a sequence number that allow the receivers to reconstruct
timing produced by the source, so that in this example, chunks
audio are contiguously played out the speaker every 20 ms.
timing reconstruction is performed separately for each source of
packets in the conference. The sequence number can also be used
the receiver to estimate how many packets are being lost
Since members of the working group join and leave during
conference, it is useful to know who is participating at any
and how well they are receiving the audio data. For that purpose
Schulzrinne, et al Standards Track [Page 5]
RFC 1889 RTP January 1996
each instance of the audio application in the conference
multicasts a reception report plus the name of its user on the
(control) port. The reception report indicates how well the
speaker is being received and may be used to control
encodings. In addition to the user name, other
information may also be included subject to control bandwidth limits
A site sends the RTCP BYE packet (Section 6.5) when it leaves
conference
2.2 Audio and Video
If both audio and video media are used in a conference, they
transmitted as separate RTP sessions RTCP packets are transmitted
each medium using two different UDP port pairs and/or
addresses. There is no direct coupling at the RTP level between
audio and video sessions, except that a user participating in
sessions should use the same distinguished (canonical) name in
RTCP packets for both so that the sessions can be associated
One motivation for this separation is to allow some participants
the conference to receive only one medium if they choose.
explanation is given in Section 5.2. Despite the separation
synchronized playback of a source's audio and video can be
using timing information carried in the RTCP packets for
sessions
2.3 Mixers and
So far, we have assumed that all sites want to receive media data
the same format. However, this may not always be appropriate
Consider the case where participants in one area are
through a low-speed link to the majority of the
participants who enjoy high-speed network access. Instead of
everyone to use a lower-bandwidth, reduced-quality audio encoding,
RTP-level relay called a mixer may be placed near the low-
area. This mixer resynchronizes incoming audio packets to
the constant 20 ms spacing generated by the sender, mixes
reconstructed audio streams into a single stream, translates
audio encoding to a lower-bandwidth one and forwards the lower
bandwidth packet stream across the low-speed link. These
might be unicast to a single recipient or multicast on a
address to multiple recipients. The RTP header includes a means
mixers to identify the sources that contributed to a mixed packet
that correct talker indication can be provided at the receivers
Some of the intended participants in the audio conference may
connected with high bandwidth links but might not be
reachable via IP multicast. For example, they might be behind
Schulzrinne, et al Standards Track [Page 6]
RFC 1889 RTP January 1996
application-level firewall that will not let any IP packets pass.
these sites, mixing may not be necessary, in which case another
of RTP-level relay called a translator may be used. Two
are installed, one on either side of the firewall, with the
one funneling all multicast packets received through a
connection to the translator inside the firewall. The
inside the firewall sends them again as multicast packets to
multicast group restricted to the site's internal network
Mixers and translators may be designed for a variety of purposes.
example is a video mixer that scales the images of individual
in separate video streams and composites them into one video
to simulate a group scene. Other examples of translation include
connection of a group of hosts speaking only IP/UDP to a group
hosts that understand only ST-II, or the packet-by-packet
translation of video streams from individual sources
resynchronization or mixing. Details of the operation of mixers
translators are given in Section 7.
3.
RTP payload: The data transported by RTP in a packet, for
audio samples or compressed video data. The payload format
interpretation are beyond the scope of this document
RTP packet: A data packet consisting of the fixed RTP header,
possibly empty list of contributing sources (see below), and
payload data. Some underlying protocols may require
encapsulation of the RTP packet to be defined. Typically
packet of the underlying protocol contains a single RTP packet
but several RTP packets may be contained if permitted by
encapsulation method (see Section 10).
RTCP packet: A control packet consisting of a fixed header
similar to that of RTP data packets, followed by
elements that vary depending upon the RTCP packet type.
formats are defined in Section 6. Typically, multiple
packets are sent together as a compound RTCP packet in a
packet of the underlying protocol; this is enabled by the
field in the fixed header of each RTCP packet
Port: The "abstraction that transport protocols use to
among multiple destinations within a given host computer. TCP/
protocols identify ports using small positive integers." [3]
transport selectors (TSEL) used by the OSI transport layer
equivalent to ports. RTP depends upon the lower-layer
to provide some mechanism such as ports to multiplex the RTP
RTCP packets of a session
Schulzrinne, et al Standards Track [Page 7]
RFC 1889 RTP January 1996
Transport address: The combination of a network address and port
identifies a transport-level endpoint, for example an IP
and a UDP port. Packets are transmitted from a source
address to a destination transport address
RTP session: The association among a set of
communicating with RTP. For each participant, the session
defined by a particular pair of destination transport
(one network address plus a port pair for RTP and RTCP).
destination transport address pair may be common for
participants, as in the case of IP multicast, or may
different for each, as in the case of individual unicast
addresses plus a common port pair. In a multimedia session
each medium is carried in a separate RTP session with its
RTCP packets. The multiple RTP sessions are distinguished
different port number pairs and/or different
addresses
Synchronization source (SSRC): The source of a stream of RTP packets
identified by a 32-bit numeric SSRC identifier carried in
RTP header so as not to be dependent upon the network address
All packets from a synchronization source form part of the
timing and sequence number space, so a receiver groups
by synchronization source for playback. Examples
synchronization sources include the sender of a stream
packets derived from a signal source such as a microphone or
camera, or an RTP mixer (see below). A synchronization
may change its data format, e.g., audio encoding, over time.
SSRC identifier is a randomly chosen value meant to be
unique within a particular RTP session (see Section 8).
participant need not use the same SSRC identifier for all
RTP sessions in a multimedia session; the binding of the
identifiers is provided through RTCP (see Section 6.4.1). If
participant generates multiple streams in one RTP session,
example from separate video cameras, each must be identified
a different SSRC
Contributing source (CSRC): A source of a stream of RTP packets
has contributed to the combined stream produced by an RTP
(see below). The mixer inserts a list of the SSRC identifiers
the sources that contributed to the generation of a
packet into the RTP header of that packet. This list is
the CSRC list. An example application is audio
where a mixer indicates all the talkers whose speech
combined to produce the outgoing packet, allowing the
to indicate the current talker, even though all the
packets contain the same SSRC identifier (that of the mixer).
Schulzrinne, et al Standards Track [Page 8]
RFC 1889 RTP January 1996
End system: An application that generates the content to be sent
RTP packets and/or consumes the content of received RTP packets
An end system can act as one or more synchronization sources
a particular RTP session, but typically only one
Mixer: An intermediate system that receives RTP packets from one
more sources, possibly changes the data format, combines
packets in some manner and then forwards a new RTP packet.
the timing among multiple input sources will not generally
synchronized, the mixer will make timing adjustments among
streams and generate its own timing for the combined stream
Thus, all data packets originating from a mixer will
identified as having the mixer as their synchronization source
Translator: An intermediate system that forwards RTP packets
their synchronization source identifier intact. Examples
translators include devices that convert encodings
mixing, replicators from multicast to unicast, and application
level filters in firewalls
Monitor: An application that receives RTCP packets sent
participants in an RTP session, in particular the
reports, and estimates the current quality of service
distribution monitoring, fault diagnosis and long-
statistics. The monitor function is likely to be built into
application(s) participating in the session, but may also be
separate application that does not otherwise participate
does not send or receive the RTP data packets. These are
third party monitors
Non-RTP means: Protocols and mechanisms that may be needed
addition to RTP to provide a usable service. In particular,
multimedia conferences, a conference control application
distribute multicast addresses and keys for encryption
negotiate the encryption algorithm to be used, and
dynamic mappings between RTP payload type values and the
formats they represent for formats that do not have a
payload type value. For simple applications, electronic mail
a conference database may also be used. The specification
such protocols and mechanisms is outside the scope of
document
4. Byte Order, Alignment, and Time
All integer fields are carried in network byte order, that is,
significant byte (octet) first. This byte order is commonly known
big-endian. The transmission order is described in detail in [4].
Unless otherwise noted, numeric constants are in decimal (base 10).
Schulzrinne, et al Standards Track [Page 9]
RFC 1889 RTP January 1996
All header data is aligned to its natural length, i.e., 16-bit
are aligned on even offsets, 32-bit fields are aligned at
divisible by four, etc. Octets designated as padding have the
zero
Wallclock time (absolute time) is represented using the
format of the Network Time Protocol (NTP), which is in
relative to 0h UTC on 1 January 1900 [5]. The full resolution
timestamp is a 64-bit unsigned fixed-point number with the
part in the first 32 bits and the fractional part in the last 32
bits. In some fields where a more compact representation
appropriate, only the middle 32 bits are used; that is, the low 16
bits of the integer part and the high 16 bits of the fractional part
The high 16 bits of the integer part must be
independently
5. RTP Data Transfer
5.1 RTP Fixed Header
The RTP header has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first twelve octets are present in every RTP packet, while
list of CSRC identifiers is present only when inserted by a mixer
The fields have the following meaning
version (V): 2
This field identifies the version of RTP. The version defined
this specification is two (2). (The value 1 is used by the
draft version of RTP and the value 0 is used by the
initially implemented in the "vat" audio tool.)
padding (P): 1
If the padding bit is set, the packet contains one or
additional padding octets at the end which are not part of
Schulzrinne, et al Standards Track [Page 10]
RFC 1889 RTP January 1996
payload. The last octet of the padding contains a count of
many padding octets should be ignored. Padding may be needed
some encryption algorithms with fixed block sizes or
carrying several RTP packets in a lower-layer protocol
unit
extension (X): 1
If the extension bit is set, the fixed header is followed
exactly one header extension, with a format defined in
5.3.1.
CSRC count (CC): 4
The CSRC count contains the number of CSRC identifiers
follow the fixed header
marker (M): 1
The interpretation of the marker is defined by a profile. It
intended to allow significant events such as frame boundaries
be marked in the packet stream. A profile may define
marker bits or specify that there is no marker bit by
the number of bits in the payload type field (see Section 5.3).
payload type (PT): 7
This field identifies the format of the RTP payload
determines its interpretation by the application. A
specifies a default static mapping of payload type codes
payload formats. Additional payload type codes may be
dynamically through non-RTP means (see Section 3). An
set of default mappings for audio and video is specified in
companion profile Internet-Draft draft-ietf-avt-profile,
may be extended in future editions of the Assigned Numbers
[6]. An RTP sender emits a single RTP payload type at any
time; this field is not intended for multiplexing separate
streams (see Section 5.2).
sequence number: 16
The sequence number increments by one for each RTP data
sent, and may be used by the receiver to detect packet loss
to restore packet sequence. The initial value of the
number is random (unpredictable) to make known-plaintext
on encryption more difficult, even if the source itself does
encrypt, because the packets may flow through a translator
does. Techniques for choosing unpredictable numbers
discussed in [7].
timestamp: 32
The timestamp reflects the sampling instant of the first
in the RTP data packet. The sampling instant must be
Schulzrinne, et al Standards Track [Page 11]
RFC 1889 RTP January 1996
from a clock that increments monotonically and linearly in
to allow synchronization and jitter calculations (see
6.3.1). The resolution of the clock must be sufficient for
desired synchronization accuracy and for measuring
arrival jitter (one tick per video frame is typically
sufficient). The clock frequency is dependent on the format
data carried as payload and is specified statically in
profile or payload format specification that defines the format
or may be specified dynamically for payload formats
through non-RTP means. If RTP packets are
periodically, the nominal sampling instant as determined
the sampling clock is to be used, not a reading of the
clock. As an example, for fixed-rate audio the timestamp
would likely increment by one for each sampling period. If
audio application reads blocks covering 160 sampling
from the input device, the timestamp would be increased by 160
for each such block, regardless of whether the block
transmitted in a packet or dropped as silent
The initial value of the timestamp is random, as for the
number. Several consecutive RTP packets may have equal timestamps
they are (logically) generated at once, e.g., belong to the
video frame. Consecutive RTP packets may contain timestamps that
not monotonic if the data is not transmitted in the order it
sampled, as in the case of MPEG interpolated video frames. (
sequence numbers of the packets as transmitted will still
monotonic.)
SSRC: 32
The SSRC field identifies the synchronization source.
identifier is chosen randomly, with the intent that no
synchronization sources within the same RTP session will
the same SSRC identifier. An example algorithm for generating
random identifier is presented in Appendix A.6. Although
probability of multiple sources choosing the same identifier
low, all RTP implementations must be prepared to detect
resolve collisions. Section 8 describes the probability
collision along with a mechanism for resolving collisions
detecting RTP-level forwarding loops based on the uniqueness
the SSRC identifier. If a source changes its source
address, it must also choose a new SSRC identifier to
being interpreted as a looped source
CSRC list: 0 to 15 items, 32 bits
The CSRC list identifies the contributing sources for
payload contained in this packet. The number of identifiers
given by the CC field. If there are more than 15
sources, only 15 may be identified. CSRC identifiers
Schulzrinne, et al Standards Track [Page 12]
RFC 1889 RTP January 1996
inserted by mixers, using the SSRC identifiers of
sources. For example, for audio packets the SSRC identifiers
all sources that were mixed together to create a packet
listed, allowing correct talker indication at the receiver
5.2 Multiplexing RTP
For efficient protocol processing, the number of multiplexing
should be minimized, as described in the integrated layer
design principle [1]. In RTP, multiplexing is provided by
destination transport address (network address and port number)
define an RTP session. For example, in a teleconference composed
audio and video media encoded separately, each medium should
carried in a separate RTP session with its own destination
address. It is not intended that the audio and video be carried in
single RTP session and demultiplexed based on the payload type
SSRC fields. Interleaving packets with different payload types
using the same SSRC would introduce several problems
1. If one payload type were switched during a session,
would be no general means to identify which of the
values the new one replaced
2. An SSRC is defined to identify a single timing and
number space. Interleaving multiple payload types
require different timing spaces if the media clock
differ and would require different sequence number
to tell which payload type suffered packet loss
3. The RTCP sender and receiver reports (see Section 6.3)
only describe one timing and sequence number space per
and do not carry a payload type field
4. An RTP mixer would not be able to combine
streams of incompatible media into one stream
5. Carrying multiple media in one RTP session precludes:
use of different network paths or network
allocations if appropriate; reception of a subset of
media if desired, for example just audio if video
exceed the available bandwidth; and
implementations that use separate processes for
different media, whereas using separate RTP
permits either single- or multiple-process implementations
Using a different SSRC for each medium but sending them in the
RTP session would avoid the first three problems but not the
two
Schulzrinne, et al Standards Track [Page 13]
RFC 1889 RTP January 1996
5.3 Profile-Specific Modifications to the RTP
The existing RTP data packet header is believed to be complete
the set of functions required in common across all the
classes that RTP might support. However, in keeping with the
design principle, the header may be tailored through modifications
additions defined in a profile specification while still
profile-independent monitoring and recording tools to function
o The marker bit and payload type field carry profile-
information, but they are allocated in the fixed header
many applications are expected to need them and might
have to add another 32-bit word just to hold them. The
containing these fields may be redefined by a profile to
different requirements, for example with a more or fewer
bits. If there are any marker bits, one should be located
the most significant bit of the octet since profile-
monitors may be able to observe a correlation between
loss patterns and the marker bit
o Additional information that is required for a
payload format, such as a video encoding, should be carried
the payload section of the packet. This might be in a
that is always present at the start of the payload section,
might be indicated by a reserved value in the data pattern
o If a particular class of applications needs
functionality independent of payload format, the profile
which those applications operate should define additional
fields to follow immediately after the SSRC field of
existing fixed header. Those applications will be able
quickly and directly access the additional fields
profile-independent monitors or recorders can still process
RTP packets by interpreting only the first twelve octets
If it turns out that additional functionality is needed in
across all profiles, then a new version of RTP should be defined
make a permanent change to the fixed header
5.3.1 RTP Header
An extension mechanism is provided to allow
implementations to experiment with new payload-format-
functions that require additional information to be carried in
RTP data packet header. This mechanism is designed so that the
extension may be ignored by other interoperating implementations
have not been extended
Schulzrinne, et al Standards Track [Page 14]
RFC 1889 RTP January 1996
Note that this header extension is intended only for limited use
Most potential uses of this mechanism would be better done
way, using the methods described in the previous section.
example, a profile-specific extension to the fixed header is
expensive to process because it is not conditional nor in a
location. Additional information required for a particular
format should not use this header extension, but should be carried
the payload section of the packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
If the X bit in the RTP header is one, a variable-length
extension is appended to the RTP header, following the CSRC list
present. The header extension contains a 16-bit length field
counts the number of 32-bit words in the extension, excluding
four-octet extension header (therefore zero is a valid length).
a single extension may be appended to the RTP data header. To
multiple interoperating implementations to each
independently with different header extensions, or to allow
particular implementation to experiment with more than one type
header extension, the first 16 bits of the header extension are
open for distinguishing identifiers or parameters. The format
these 16 bits is to be defined by the profile specification
which the implementations are operating. This RTP specification
not define any header extensions itself
6. RTP Control Protocol --
The RTP control protocol (RTCP) is based on the periodic
of control packets to all participants in the session, using the
distribution mechanism as the data packets. The underlying
must provide multiplexing of the data and control packets,
example using separate port numbers with UDP. RTCP performs
functions
1. The primary function is to provide feedback on the
of the data distribution. This is an integral part of
RTP's role as a transport protocol and is related to
flow and congestion control functions of other
protocols. The feedback may be directly useful for
of adaptive encodings [8,9], but experiments with
Schulzrinne, et al Standards Track [Page 15]
RFC 1889 RTP January 1996
multicasting have shown that it is also critical to
feedback from the receivers to diagnose faults in
distribution. Sending reception feedback reports to
participants allows one who is observing problems
evaluate whether those problems are local or global. With
distribution mechanism like IP multicast, it is
possible for an entity such as a network service
who is not otherwise involved in the session to receive
feedback information and act as a third-party monitor
diagnose network problems. This feedback function
performed by the RTCP sender and receiver reports
described below in Section 6.3.
2. RTCP carries a persistent transport-level identifier for
RTP source called the canonical name or CNAME,
6.4.1. Since the SSRC identifier may change if a
is discovered or a program is restarted, receivers
the CNAME to keep track of each participant. Receivers
require the CNAME to associate multiple data streams from
given participant in a set of related RTP sessions,
example to synchronize audio and video
3. The first two functions require that all participants
RTCP packets, therefore the rate must be controlled
order for RTP to scale up to a large number
participants. By having each participant send its
packets to all the others, each can independently
the number of participants. This number is used
calculate the rate at which the packets are sent,
explained in Section 6.2.
4. A fourth, optional function is to convey minimal
control information, for example participant
to be displayed in the user interface. This is most
to be useful in "loosely controlled" sessions
participants enter and leave without membership control
parameter negotiation. RTCP serves as a convenient
to reach all the participants, but it is not
expected to support all the control
requirements of an application. A higher-level
control protocol, which is beyond the scope of
document, may be needed
Functions 1-3 are mandatory when RTP is used in the IP
environment, and are recommended for all environments.
application designers are advised to avoid mechanisms that can
work in unicast mode and will not scale to larger numbers
Schulzrinne, et al Standards Track [Page 16]
RFC 1889 RTP January 1996
6.1 RTCP Packet
This specification defines several RTCP packet types to carry
variety of control information
SR: Sender report, for transmission and reception statistics
participants that are active
RR: Receiver report, for reception statistics from participants
are not active
SDES: Source description items, including
BYE: Indicates end of
APP: Application specific
Each RTCP packet begins with a fixed part similar to that of RTP
packets, followed by structured elements that may be of
length according to the packet type but always end on a 32-
boundary. The alignment requirement and a length field in the
part are included to make RTCP packets "stackable". Multiple
packets may be concatenated without any intervening separators
form a compound RTCP packet that is sent in a single packet of
lower layer protocol, for example UDP. There is no explicit count
individual RTCP packets in the compound packet since the lower
protocols are expected to provide an overall length to determine
end of the compound packet
Each individual RTCP packet in the compound packet may be
independently with no requirements upon the order or combination
packets. However, in order to perform the functions of the protocol
the following constraints are imposed
o Reception statistics (in SR or RR) should be sent as often
bandwidth constraints will allow to maximize the resolution
the statistics, therefore each periodically
compound RTCP packet should include a report packet
o New receivers need to receive the CNAME for a source as
as possible to identify the source and to begin
media for purposes such as lip-sync, so each compound
packet should also include the SDES CNAME
o The number of packet types that may appear first in
compound packet should be limited to increase the number
constant bits in the first word and the probability
successfully validating RTCP packets against misaddressed
Schulzrinne, et al Standards Track [Page 17]
RFC 1889 RTP January 1996
data packets or other unrelated packets
Thus, all RTCP packets must be sent in a compound packet of at
two individual packets, with the following format recommended
Encryption prefix: If and only if the compound packet is to
encrypted, it is prefixed by a random 32-bit quantity
for every compound packet transmitted
SR or RR: The first RTCP packet in the compound packet must
be a report packet to facilitate header validation as
in Appendix A.2. This is true even if no data has been sent
received, in which case an empty RR is sent, and even if
only other RTCP packet in the compound packet is a BYE
Additional RRs: If the number of sources for which
statistics are being reported exceeds 31, the number that
fit into one SR or RR packet, then additional RR packets
follow the initial report packet
SDES: An SDES packet containing a CNAME item must be included
each compound RTCP packet. Other source description items
optionally be included if required by a particular application
subject to bandwidth constraints (see Section 6.2.2).
BYE or APP: Other RTCP packet types, including those yet to
defined, may follow in any order, except that BYE should be
last packet sent with a given SSRC/CSRC. Packet types may
more than once
It is advisable for translators and mixers to combine individual
packets from the multiple sources they are forwarding into
compound packet whenever feasible in order to amortize the
overhead (see Section 7). An example RTCP compound packet as might
produced by a mixer is shown in Fig. 1. If the overall length of
compound packet would exceed the maximum transmission unit (MTU)
the network path, it may be segmented into multiple shorter
packets to be transmitted in separate packets of the
protocol. Note that each of the compound packets must begin with
SR or RR packet
An implementation may ignore incoming RTCP packets with types
to it. Additional RTCP packet types may be registered with
Internet Assigned Numbers Authority (IANA).
Schulzrinne, et al Standards Track [Page 18]
RFC 1889 RTP January 1996
6.2 RTCP Transmission
if encrypted: random 32-bit
|
|[------- packet -------][----------- packet -----------][-packet-]
|
| receiver reports chunk
V item item item
--------------------------------------------------------------------
|R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why
|R[ |# report # 1 # 2 ][ |# |# ][ ## ]
|R[ |# # # ][ |# |# ][ ## ]
|R[ |# # # ][ |# |# ][ ## ]
--------------------------------------------------------------------
|<------------------ UDP packet (compound packet) --------------->|
#: SSRC/
Figure 1: Example of an RTCP compound
RTP is designed to allow an application to scale automatically
session sizes ranging from a few participants to thousands.
example, in an audio conference the data traffic is inherently self
limiting because only one or two people will speak at a time, so
multicast distribution the data rate on any given link
relatively constant independent of the number of participants
However, the control traffic is not self-limiting. If the
reports from each participant were sent at a constant rate,
control traffic would grow linearly with the number of participants
Therefore, the rate must be scaled down
For each session, it is assumed that the data traffic is subject
an aggregate limit called the "session bandwidth" to be divided
the participants. This bandwidth might be reserved and the
enforced by the network, or it might just be a reasonable share.
session bandwidth may be chosen based or some cost or a
knowledge of the available network bandwidth for the session. It
somewhat independent of the media encoding, but the encoding
may be limited by the session bandwidth. The session
parameter is expected to be supplied by a session
application when it invokes a media application, but
applications may also set a default based on the single-sender
bandwidth for the encoding selected for the session. The
may also enforce bandwidth limits based on multicast scope rules
other criteria
Schulzrinne, et al Standards Track [Page 19]
RFC 1889 RTP January 1996
Bandwidth calculations for control and data traffic include lower
layer transport and network protocols (e.g., UDP and IP) since
is what the resource reservation system would need to know.
application can also be expected to know which of these protocols
in use. Link level headers are not included in the calculation
the packet will be encapsulated with different link level headers
it travels
The control traffic should be limited to a small and known
of the session bandwidth: small so that the primary function of
transport protocol to carry data is not impaired; known so that
control traffic can be included in the bandwidth specification
to a resource reservation protocol, and so that each participant
independently calculate its share. It is suggested that the
of the session bandwidth allocated to RTCP be fixed at 5%. While
value of this and other constants in the interval calculation is
critical, all participants in the session must use the same values
the same interval will be calculated. Therefore, these
should be fixed for a particular profile
The algorithm described in Appendix A.7 was designed to meet
goals outlined above. It calculates the interval between
compound RTCP packets to divide the allowed control traffic
among the participants. This allows an application to provide
response for small sessions where, for example, identification of
participants is important, yet automatically adapt to large sessions
The algorithm incorporates the following characteristics
o Senders are collectively allocated at least 1/4 of the
traffic bandwidth so that in sessions with a large number
receivers but a small number of senders, newly
participants will more quickly receive the CNAME for
sending sites
o The calculated interval between RTCP packets is required to
greater than a minimum of 5 seconds to avoid having bursts
RTCP packets exceed the allowed bandwidth when the number
participants is small and the traffic isn't smoothed
to the law of large numbers
o The interval between RTCP packets is varied randomly over
range [0.5,1.5] times the calculated interval to
unintended synchronization of all participants [10]. The
RTCP packet sent after joining a session is also delayed by
random variation of half the minimum RTCP interval in case
application is started at multiple sites simultaneously,
example as initiated by a session announcement
Schulzrinne, et al Standards Track [Page 20]
RFC 1889 RTP January 1996
o A dynamic estimate of the average compound RTCP packet size
calculated, including all those received and sent,
automatically adapt to changes in the amount of
information carried
This algorithm may be used for sessions in which all participants
allowed to send. In that case, the session bandwidth parameter is
product of the individual sender's bandwidth times the number
participants, and the RTCP bandwidth is 5% of that
6.2.1 Maintaining the number of session
Calculation of the RTCP packet interval depends upon an estimate
the number of sites participating in the session. New sites are
to the count when they are heard, and an entry for each is created
a table indexed by the SSRC or CSRC identifier (see Section 8.2)
keep track of them. New entries may not be considered valid
multiple packets carrying the new SSRC have been received (
Appendix A.1). Entries may be deleted from the table when an RTCP
packet with the corresponding SSRC identifier is received
A participant may mark another site inactive, or delete it if not
valid, if no RTP or RTCP packet has been received for a small
of RTCP report intervals (5 is suggested). This provides
robustness against packet loss. All sites must calculate roughly
same value for the RTCP report interval in order for this timeout
work properly
Once a site has been validated, then if it is later marked
the state for that site should still be retained and the site
continue to be counted in the total number of sites sharing
bandwidth for a period long enough to span typical
partitions. This is to avoid excessive traffic, when the
heals, due to an RTCP report interval that is too small. A timeout
30 minutes is suggested. Note that this is still larger than 5
the largest value to which the RTCP report interval is expected
usefully scale, about 2 to 5 minutes
6.2.2 Allocation of source description
This specification defines several source description (SDES) items
addition to the mandatory CNAME item, such as NAME (personal name
and EMAIL (email address). It also provides a means to define
application-specific RTCP packet types. Applications should
caution in allocating control bandwidth to this
information because it will slow down the rate at which
reports and CNAME are sent, thus impairing the performance of
protocol. It is recommended that no more than 20% of the
Schulzrinne, et al Standards Track [Page 21]
RFC 1889 RTP January 1996
bandwidth allocated to a single participant be used to carry
additional information. Furthermore, it is not intended that
SDES items should be included in every application. Those that
included should be assigned a fraction of the bandwidth according
their utility. Rather than estimate these fractions dynamically,
is recommended that the percentages be translated statically
report interval counts based on the typical length of an item
For example, an application may be designed to send only CNAME,
and EMAIL and not any others. NAME might be given much
priority than EMAIL because the NAME would be displayed
in the application's user interface, whereas EMAIL would be
only when requested. At every RTCP interval, an RR packet and an
packet with the CNAME item would be sent. For a small
operating at the minimum interval, that would be every 5 seconds
the average. Every third interval (15 seconds), one extra item
be included in the SDES packet. Seven out of eight times this
be the NAME item, and every eighth time (2 minutes) it would be
EMAIL item
When multiple applications operate in concert using cross-
binding through a common CNAME for each participant, for example in
multimedia conference composed of an RTP session for each medium,
additional SDES information might be sent in only one RTP session
The other sessions would carry only the CNAME item
6.3 Sender and Receiver
RTP receivers provide reception quality feedback using RTCP
packets which may take one of two forms depending upon whether or
the receiver is also a sender. The only difference between the
report (SR) and receiver report (RR) forms, besides the packet
code, is that the sender report includes a 20-byte sender
section for use by active senders. The SR is issued if a site
sent any data packets during the interval since issuing the
report or the previous one, otherwise the RR is issued
Both the SR and RR forms include zero or more reception
blocks, one for each of the synchronization sources from which
receiver has received RTP data packets since the last report.
are not issued for contributing sources listed in the CSRC list.
reception report block provides statistics about the data
from the particular source indicated in that block. Since a
of 31 reception report blocks will fit in an SR or RR packet
additional RR packets may be stacked after the initial SR or
packet as needed to contain the reception reports for all
heard during the interval since the last report
Schulzrinne, et al Standards Track [Page 22]
RFC 1889 RTP January 1996
The next sections define the formats of the two reports, how they
be extended in a profile-specific manner if an application
additional feedback information, and how the reports may be used
Details of reception reporting by translators and mixers is given
Section 7.
6.3.1 SR: Sender report RTCP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fraction lost | cumulative number of packets lost | 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender report packet consists of three sections,
followed by a fourth profile-specific extension section if defined
The first section, the header, is 8 octets long. The fields have
following meaning
Schulzrinne, et al Standards Track [Page 23]
RFC 1889 RTP January 1996
version (V): 2
Identifies the version of RTP, which is the same in RTCP
as in RTP data packets. The version defined by
specification is two (2).
padding (P): 1
If the padding bit is set, this RTCP packet contains
additional padding octets at the end which are not part of
control information. The last octet of the padding is a count
how many padding octets should be ignored. Padding may be
by some encryption algorithms with fixed block sizes. In
compound RTCP packet, padding should only be required on
las