流媒体/Mpeg4/MP4

开发平台：

C/C++

RFC1889.txt：源码内容

START
Network Working Group Audio-Video Transport Working Group
Request for Comments: 1889 H. Schulzrinne
Category: Standards Track GMD Fokus
S. Casner
Precept Software, Inc.
R. Frederick
Xerox Palo Alto Research Center
V. Jacobson
Lawrence Berkeley National Laboratory
January 1996
RTP: A Transport Protocol for Real-Time Applications
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
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.
Table of Contents
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 and
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. Introduction
This memorandum specifies the real-time transport protocol (RTP),
which provides end-to-end delivery services for data with real-time
characteristics, such as interactive audio and video. Those services
include payload type identification, sequence numbering, timestamping
and delivery monitoring. Applications typically run RTP on top of UDP
to make use of its multiplexing and checksum services; both protocols
contribute parts of the transport protocol functionality. However,
RTP may be used with other suitable underlying network or transport
protocols (see Section 10). RTP supports data transfer to multiple
destinations using multicast distribution if provided by the
underlying network.
Note that RTP itself does not provide any mechanism to ensure timely
delivery or provide other quality-of-service guarantees, but relies
on lower-layer services to do so. It does not guarantee delivery or
prevent out-of-order delivery, nor does it assume that the underlying
network is reliable and delivers packets in sequence. The sequence
numbers included in RTP allow the receiver to reconstruct the
sender's packet sequence, but sequence numbers might also be used to
determine the proper location of a packet, for example in video
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 that
particular application. Storage of continuous data, interactive
distributed simulation, active badge, and control and measurement
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 has
real-time properties.
o the RTP control protocol (RTCP), to monitor the quality of
service and to convey information about the participants in an
on-going session. The latter aspect of RTCP may be sufficient
for "loosely controlled" sessions, i.e., where there is no
explicit membership control and set-up, but it is not
necessarily intended to support all of an application's control
communication requirements. This functionality may be fully or
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 of
application level framing and integrated layer processing proposed by
Clark and Tennenhouse [1]. That is, RTP is intended to be malleable
to provide the information required by a particular application and
will often be integrated into the application processing rather than
being implemented as a separate layer. RTP is a protocol framework
that is deliberately not complete. This document specifies those
functions expected to be common across all the applications for which
RTP would be appropriate. Unlike conventional protocols in which
additional functions might be accommodated by making the protocol
more general or by adding an option mechanism that would require
parsing, RTP is intended to be tailored through modifications and/or
additions to the headers as needed. Examples are given in Sections
5.3 and 6.3.3.
Therefore, in addition to this document, a complete specification of
RTP for a particular application will require one or more companion
documents (see Section 12):
o a profile specification document, which defines a set of
payload type codes and their mapping to payload formats (e.g.,
media encodings). A profile may also define extensions or
modifications to RTP that are specific to a particular class of
applications. Typically an application will operate under only
one profile. A profile for audio and video data may be found in
the companion RFC TBD.
o payload format specification documents, which define how a
particular payload, such as an audio or video encoding, is to
be carried in RTP.
A discussion of real-time services and algorithms for their
implementation as well as background discussion on some of the RTP
design decisions can be found in [2].
Several RTP applications, both experimental and commercial, have
already been implemented from draft specifications. These
applications include audio and video tools along with diagnostic
tools such as traffic monitors. Users of these tools number in the
thousands. However, the current Internet cannot yet support the full
potential demand for real-time services. High-bandwidth services
using RTP, such as video, can potentially seriously degrade the
quality of service of other network services. Thus, implementors
should take appropriate precautions to limit accidental bandwidth
usage. Application documentation should clearly outline the
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 Scenarios
The following sections describe some aspects of the use of RTP. The
examples were chosen to illustrate the basic operation of
applications using RTP, not to limit what RTP may be used for. In
these examples, RTP is carried on top of IP and UDP, and follows the
conventions established by the profile for audio and video specified
in the companion Internet-Draft draft-ietf-avt-profile
2.1 Simple Multicast Audio Conference
A working group of the IETF meets to discuss the latest protocol
draft, using the IP multicast services of the Internet for voice
communications. Through some allocation mechanism the working group
chair obtains a multicast group address and pair of ports. One port
is used for audio data, and the other is used for control (RTCP)
packets. This address and port information is distributed to the
intended participants. If privacy is desired, the data and control
packets may be encrypted as specified in Section 9.1, in which case
an encryption key must also be generated and distributed. The exact
details of these allocation and distribution mechanisms are beyond
the scope of RTP.
The audio conferencing application used by each conference
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 and
data are in turn contained in a UDP packet. The RTP header indicates
what type of audio encoding (such as PCM, ADPCM or LPC) is contained
in each packet so that senders can change the encoding during a
conference, for example, to accommodate a new participant that is
connected through a low-bandwidth link or react to indications of
network congestion.
The Internet, like other packet networks, occasionally loses and
reorders packets and delays them by variable amounts of time. To cope
with these impairments, the RTP header contains timing information
and a sequence number that allow the receivers to reconstruct the
timing produced by the source, so that in this example, chunks of
audio are contiguously played out the speaker every 20 ms. This
timing reconstruction is performed separately for each source of RTP
packets in the conference. The sequence number can also be used by
the receiver to estimate how many packets are being lost.
Since members of the working group join and leave during the
conference, it is useful to know who is participating at any moment
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 periodically
multicasts a reception report plus the name of its user on the RTCP
(control) port. The reception report indicates how well the current
speaker is being received and may be used to control adaptive
encodings. In addition to the user name, other identifying
information may also be included subject to control bandwidth limits.
A site sends the RTCP BYE packet (Section 6.5) when it leaves the
conference.
2.2 Audio and Video Conference
If both audio and video media are used in a conference, they are
transmitted as separate RTP sessions RTCP packets are transmitted for
each medium using two different UDP port pairs and/or multicast
addresses. There is no direct coupling at the RTP level between the
audio and video sessions, except that a user participating in both
sessions should use the same distinguished (canonical) name in the
RTCP packets for both so that the sessions can be associated.
One motivation for this separation is to allow some participants in
the conference to receive only one medium if they choose. Further
explanation is given in Section 5.2. Despite the separation,
synchronized playback of a source's audio and video can be achieved
using timing information carried in the RTCP packets for both
sessions.
2.3 Mixers and Translators
So far, we have assumed that all sites want to receive media data in
the same format. However, this may not always be appropriate.
Consider the case where participants in one area are connected
through a low-speed link to the majority of the conference
participants who enjoy high-speed network access. Instead of forcing
everyone to use a lower-bandwidth, reduced-quality audio encoding, an
RTP-level relay called a mixer may be placed near the low-bandwidth
area. This mixer resynchronizes incoming audio packets to reconstruct
the constant 20 ms spacing generated by the sender, mixes these
reconstructed audio streams into a single stream, translates the
audio encoding to a lower-bandwidth one and forwards the lower-
bandwidth packet stream across the low-speed link. These packets
might be unicast to a single recipient or multicast on a different
address to multiple recipients. The RTP header includes a means for
mixers to identify the sources that contributed to a mixed packet so
that correct talker indication can be provided at the receivers.
Some of the intended participants in the audio conference may be
connected with high bandwidth links but might not be directly
reachable via IP multicast. For example, they might be behind an
Schulzrinne, et al Standards Track [Page 6]
RFC 1889 RTP January 1996
application-level firewall that will not let any IP packets pass. For
these sites, mixing may not be necessary, in which case another type
of RTP-level relay called a translator may be used. Two translators
are installed, one on either side of the firewall, with the outside
one funneling all multicast packets received through a secure
connection to the translator inside the firewall. The translator
inside the firewall sends them again as multicast packets to a
multicast group restricted to the site's internal network.
Mixers and translators may be designed for a variety of purposes. An
example is a video mixer that scales the images of individual people
in separate video streams and composites them into one video stream
to simulate a group scene. Other examples of translation include the
connection of a group of hosts speaking only IP/UDP to a group of
hosts that understand only ST-II, or the packet-by-packet encoding
translation of video streams from individual sources without
resynchronization or mixing. Details of the operation of mixers and
translators are given in Section 7.
3. Definitions
RTP payload: The data transported by RTP in a packet, for example
audio samples or compressed video data. The payload format and
interpretation are beyond the scope of this document.
RTP packet: A data packet consisting of the fixed RTP header, a
possibly empty list of contributing sources (see below), and the
payload data. Some underlying protocols may require an
encapsulation of the RTP packet to be defined. Typically one
packet of the underlying protocol contains a single RTP packet,
but several RTP packets may be contained if permitted by the
encapsulation method (see Section 10).
RTCP packet: A control packet consisting of a fixed header part
similar to that of RTP data packets, followed by structured
elements that vary depending upon the RTCP packet type. The
formats are defined in Section 6. Typically, multiple RTCP
packets are sent together as a compound RTCP packet in a single
packet of the underlying protocol; this is enabled by the length
field in the fixed header of each RTCP packet.
Port: The "abstraction that transport protocols use to distinguish
among multiple destinations within a given host computer. TCP/IP
protocols identify ports using small positive integers." [3] The
transport selectors (TSEL) used by the OSI transport layer are
equivalent to ports. RTP depends upon the lower-layer protocol
to provide some mechanism such as ports to multiplex the RTP and
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 that
identifies a transport-level endpoint, for example an IP address
and a UDP port. Packets are transmitted from a source transport
address to a destination transport address.
RTP session: The association among a set of participants
communicating with RTP. For each participant, the session is
defined by a particular pair of destination transport addresses
(one network address plus a port pair for RTP and RTCP). The
destination transport address pair may be common for all
participants, as in the case of IP multicast, or may be
different for each, as in the case of individual unicast network
addresses plus a common port pair. In a multimedia session,
each medium is carried in a separate RTP session with its own
RTCP packets. The multiple RTP sessions are distinguished by
different port number pairs and/or different multicast
addresses.
Synchronization source (SSRC): The source of a stream of RTP packets,
identified by a 32-bit numeric SSRC identifier carried in the
RTP header so as not to be dependent upon the network address.
All packets from a synchronization source form part of the same
timing and sequence number space, so a receiver groups packets
by synchronization source for playback. Examples of
synchronization sources include the sender of a stream of
packets derived from a signal source such as a microphone or a
camera, or an RTP mixer (see below). A synchronization source
may change its data format, e.g., audio encoding, over time. The
SSRC identifier is a randomly chosen value meant to be globally
unique within a particular RTP session (see Section 8). A
participant need not use the same SSRC identifier for all the
RTP sessions in a multimedia session; the binding of the SSRC
identifiers is provided through RTCP (see Section 6.4.1). If a
participant generates multiple streams in one RTP session, for
example from separate video cameras, each must be identified as
a different SSRC.
Contributing source (CSRC): A source of a stream of RTP packets that
has contributed to the combined stream produced by an RTP mixer
(see below). The mixer inserts a list of the SSRC identifiers of
the sources that contributed to the generation of a particular
packet into the RTP header of that packet. This list is called
the CSRC list. An example application is audio conferencing
where a mixer indicates all the talkers whose speech was
combined to produce the outgoing packet, allowing the receiver
to indicate the current talker, even though all the audio
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 in
RTP packets and/or consumes the content of received RTP packets.
An end system can act as one or more synchronization sources in
a particular RTP session, but typically only one.
Mixer: An intermediate system that receives RTP packets from one or
more sources, possibly changes the data format, combines the
packets in some manner and then forwards a new RTP packet. Since
the timing among multiple input sources will not generally be
synchronized, the mixer will make timing adjustments among the
streams and generate its own timing for the combined stream.
Thus, all data packets originating from a mixer will be
identified as having the mixer as their synchronization source.
Translator: An intermediate system that forwards RTP packets with
their synchronization source identifier intact. Examples of
translators include devices that convert encodings without
mixing, replicators from multicast to unicast, and application-
level filters in firewalls.
Monitor: An application that receives RTCP packets sent by
participants in an RTP session, in particular the reception
reports, and estimates the current quality of service for
distribution monitoring, fault diagnosis and long-term
statistics. The monitor function is likely to be built into the
application(s) participating in the session, but may also be a
separate application that does not otherwise participate and
does not send or receive the RTP data packets. These are called
third party monitors.
Non-RTP means: Protocols and mechanisms that may be needed in
addition to RTP to provide a usable service. In particular, for
multimedia conferences, a conference control application may
distribute multicast addresses and keys for encryption,
negotiate the encryption algorithm to be used, and define
dynamic mappings between RTP payload type values and the payload
formats they represent for formats that do not have a predefined
payload type value. For simple applications, electronic mail or
a conference database may also be used. The specification of
such protocols and mechanisms is outside the scope of this
document.
4. Byte Order, Alignment, and Time Format
All integer fields are carried in network byte order, that is, most
significant byte (octet) first. This byte order is commonly known as
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 fields
are aligned on even offsets, 32-bit fields are aligned at offsets
divisible by four, etc. Octets designated as padding have the value
zero.
Wallclock time (absolute time) is represented using the timestamp
format of the Network Time Protocol (NTP), which is in seconds
relative to 0h UTC on 1 January 1900 [5]. The full resolution NTP
timestamp is a 64-bit unsigned fixed-point number with the integer
part in the first 32 bits and the fractional part in the last 32
bits. In some fields where a more compact representation is
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 determined
independently.
5. RTP Data Transfer Protocol
5.1 RTP Fixed Header Fields
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 the
list of CSRC identifiers is present only when inserted by a mixer.
The fields have the following meaning:
version (V): 2 bits
This field identifies the version of RTP. The version defined by
this specification is two (2). (The value 1 is used by the first
draft version of RTP and the value 0 is used by the protocol
initially implemented in the "vat" audio tool.)
padding (P): 1 bit
If the padding bit is set, the packet contains one or more
additional padding octets at the end which are not part of the
Schulzrinne, et al Standards Track [Page 10]
RFC 1889 RTP January 1996
payload. The last octet of the padding contains a count of how
many padding octets should be ignored. Padding may be needed by
some encryption algorithms with fixed block sizes or for
carrying several RTP packets in a lower-layer protocol data
unit.
extension (X): 1 bit
If the extension bit is set, the fixed header is followed by
exactly one header extension, with a format defined in Section
5.3.1.
CSRC count (CC): 4 bits
The CSRC count contains the number of CSRC identifiers that
follow the fixed header.
marker (M): 1 bit
The interpretation of the marker is defined by a profile. It is
intended to allow significant events such as frame boundaries to
be marked in the packet stream. A profile may define additional
marker bits or specify that there is no marker bit by changing
the number of bits in the payload type field (see Section 5.3).
payload type (PT): 7 bits
This field identifies the format of the RTP payload and
determines its interpretation by the application. A profile
specifies a default static mapping of payload type codes to
payload formats. Additional payload type codes may be defined
dynamically through non-RTP means (see Section 3). An initial
set of default mappings for audio and video is specified in the
companion profile Internet-Draft draft-ietf-avt-profile, and
may be extended in future editions of the Assigned Numbers RFC
[6]. An RTP sender emits a single RTP payload type at any given
time; this field is not intended for multiplexing separate media
streams (see Section 5.2).
sequence number: 16 bits
The sequence number increments by one for each RTP data packet
sent, and may be used by the receiver to detect packet loss and
to restore packet sequence. The initial value of the sequence
number is random (unpredictable) to make known-plaintext attacks
on encryption more difficult, even if the source itself does not
encrypt, because the packets may flow through a translator that
does. Techniques for choosing unpredictable numbers are
discussed in [7].
timestamp: 32 bits
The timestamp reflects the sampling instant of the first octet
in the RTP data packet. The sampling instant must be derived
Schulzrinne, et al Standards Track [Page 11]
RFC 1889 RTP January 1996
from a clock that increments monotonically and linearly in time
to allow synchronization and jitter calculations (see Section
6.3.1). The resolution of the clock must be sufficient for the
desired synchronization accuracy and for measuring packet
arrival jitter (one tick per video frame is typically not
sufficient). The clock frequency is dependent on the format of
data carried as payload and is specified statically in the
profile or payload format specification that defines the format,
or may be specified dynamically for payload formats defined
through non-RTP means. If RTP packets are generated
periodically, the nominal sampling instant as determined from
the sampling clock is to be used, not a reading of the system
clock. As an example, for fixed-rate audio the timestamp clock
would likely increment by one for each sampling period. If an
audio application reads blocks covering 160 sampling periods
from the input device, the timestamp would be increased by 160
for each such block, regardless of whether the block is
transmitted in a packet or dropped as silent.
The initial value of the timestamp is random, as for the sequence
number. Several consecutive RTP packets may have equal timestamps if
they are (logically) generated at once, e.g., belong to the same
video frame. Consecutive RTP packets may contain timestamps that are
not monotonic if the data is not transmitted in the order it was
sampled, as in the case of MPEG interpolated video frames. (The
sequence numbers of the packets as transmitted will still be
monotonic.)
SSRC: 32 bits
The SSRC field identifies the synchronization source. This
identifier is chosen randomly, with the intent that no two
synchronization sources within the same RTP session will have
the same SSRC identifier. An example algorithm for generating a
random identifier is presented in Appendix A.6. Although the
probability of multiple sources choosing the same identifier is
low, all RTP implementations must be prepared to detect and
resolve collisions. Section 8 describes the probability of
collision along with a mechanism for resolving collisions and
detecting RTP-level forwarding loops based on the uniqueness of
the SSRC identifier. If a source changes its source transport
address, it must also choose a new SSRC identifier to avoid
being interpreted as a looped source.
CSRC list: 0 to 15 items, 32 bits each
The CSRC list identifies the contributing sources for the
payload contained in this packet. The number of identifiers is
given by the CC field. If there are more than 15 contributing
sources, only 15 may be identified. CSRC identifiers are
Schulzrinne, et al Standards Track [Page 12]
RFC 1889 RTP January 1996
inserted by mixers, using the SSRC identifiers of contributing
sources. For example, for audio packets the SSRC identifiers of
all sources that were mixed together to create a packet are
listed, allowing correct talker indication at the receiver.
5.2 Multiplexing RTP Sessions
For efficient protocol processing, the number of multiplexing points
should be minimized, as described in the integrated layer processing
design principle [1]. In RTP, multiplexing is provided by the
destination transport address (network address and port number) which
define an RTP session. For example, in a teleconference composed of
audio and video media encoded separately, each medium should be
carried in a separate RTP session with its own destination transport
address. It is not intended that the audio and video be carried in a
single RTP session and demultiplexed based on the payload type or
SSRC fields. Interleaving packets with different payload types but
using the same SSRC would introduce several problems:
1. If one payload type were switched during a session, there
would be no general means to identify which of the old
values the new one replaced.
2. An SSRC is defined to identify a single timing and sequence
number space. Interleaving multiple payload types would
require different timing spaces if the media clock rates
differ and would require different sequence number spaces
to tell which payload type suffered packet loss.
3. The RTCP sender and receiver reports (see Section 6.3) can
only describe one timing and sequence number space per SSRC
and do not carry a payload type field.
4. An RTP mixer would not be able to combine interleaved
streams of incompatible media into one stream.
5. Carrying multiple media in one RTP session precludes: the
use of different network paths or network resource
allocations if appropriate; reception of a subset of the
media if desired, for example just audio if video would
exceed the available bandwidth; and receiver
implementations that use separate processes for the
different media, whereas using separate RTP sessions
permits either single- or multiple-process implementations.
Using a different SSRC for each medium but sending them in the same
RTP session would avoid the first three problems but not the last
two.
Schulzrinne, et al Standards Track [Page 13]
RFC 1889 RTP January 1996
5.3 Profile-Specific Modifications to the RTP Header
The existing RTP data packet header is believed to be complete for
the set of functions required in common across all the application
classes that RTP might support. However, in keeping with the ALF
design principle, the header may be tailored through modifications or
additions defined in a profile specification while still allowing
profile-independent monitoring and recording tools to function.
o The marker bit and payload type field carry profile-specific
information, but they are allocated in the fixed header since
many applications are expected to need them and might otherwise
have to add another 32-bit word just to hold them. The octet
containing these fields may be redefined by a profile to suit
different requirements, for example with a more or fewer marker
bits. If there are any marker bits, one should be located in
the most significant bit of the octet since profile-independent
monitors may be able to observe a correlation between packet
loss patterns and the marker bit.
o Additional information that is required for a particular
payload format, such as a video encoding, should be carried in
the payload section of the packet. This might be in a header
that is always present at the start of the payload section, or
might be indicated by a reserved value in the data pattern.
o If a particular class of applications needs additional
functionality independent of payload format, the profile under
which those applications operate should define additional fixed
fields to follow immediately after the SSRC field of the
existing fixed header. Those applications will be able to
quickly and directly access the additional fields while
profile-independent monitors or recorders can still process the
RTP packets by interpreting only the first twelve octets.
If it turns out that additional functionality is needed in common
across all profiles, then a new version of RTP should be defined to
make a permanent change to the fixed header.
5.3.1 RTP Header Extension
An extension mechanism is provided to allow individual
implementations to experiment with new payload-format-independent
functions that require additional information to be carried in the
RTP data packet header. This mechanism is designed so that the header
extension may be ignored by other interoperating implementations that
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 another
way, using the methods described in the previous section. For
example, a profile-specific extension to the fixed header is less
expensive to process because it is not conditional nor in a variable
location. Additional information required for a particular payload
format should not use this header extension, but should be carried in
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 header
extension is appended to the RTP header, following the CSRC list if
present. The header extension contains a 16-bit length field that
counts the number of 32-bit words in the extension, excluding the
four-octet extension header (therefore zero is a valid length). Only
a single extension may be appended to the RTP data header. To allow
multiple interoperating implementations to each experiment
independently with different header extensions, or to allow a
particular implementation to experiment with more than one type of
header extension, the first 16 bits of the header extension are left
open for distinguishing identifiers or parameters. The format of
these 16 bits is to be defined by the profile specification under
which the implementations are operating. This RTP specification does
not define any header extensions itself.
6. RTP Control Protocol -- RTCP
The RTP control protocol (RTCP) is based on the periodic transmission
of control packets to all participants in the session, using the same
distribution mechanism as the data packets. The underlying protocol
must provide multiplexing of the data and control packets, for
example using separate port numbers with UDP. RTCP performs four
functions:
1. The primary function is to provide feedback on the quality
of the data distribution. This is an integral part of the
RTP's role as a transport protocol and is related to the
flow and congestion control functions of other transport
protocols. The feedback may be directly useful for control
of adaptive encodings [8,9], but experiments with IP
Schulzrinne, et al Standards Track [Page 15]
RFC 1889 RTP January 1996
multicasting have shown that it is also critical to get
feedback from the receivers to diagnose faults in the
distribution. Sending reception feedback reports to all
participants allows one who is observing problems to
evaluate whether those problems are local or global. With a
distribution mechanism like IP multicast, it is also
possible for an entity such as a network service provider
who is not otherwise involved in the session to receive the
feedback information and act as a third-party monitor to
diagnose network problems. This feedback function is
performed by the RTCP sender and receiver reports,
described below in Section 6.3.
2. RTCP carries a persistent transport-level identifier for an
RTP source called the canonical name or CNAME, Section
6.4.1. Since the SSRC identifier may change if a conflict
is discovered or a program is restarted, receivers require
the CNAME to keep track of each participant. Receivers also
require the CNAME to associate multiple data streams from a
given participant in a set of related RTP sessions, for
example to synchronize audio and video.
3. The first two functions require that all participants send
RTCP packets, therefore the rate must be controlled in
order for RTP to scale up to a large number of
participants. By having each participant send its control
packets to all the others, each can independently observe
the number of participants. This number is used to
calculate the rate at which the packets are sent, as
explained in Section 6.2.
4. A fourth, optional function is to convey minimal session
control information, for example participant identification
to be displayed in the user interface. This is most likely
to be useful in "loosely controlled" sessions where
participants enter and leave without membership control or
parameter negotiation. RTCP serves as a convenient channel
to reach all the participants, but it is not necessarily
expected to support all the control communication
requirements of an application. A higher-level session
control protocol, which is beyond the scope of this
document, may be needed.
Functions 1-3 are mandatory when RTP is used in the IP multicast
environment, and are recommended for all environments. RTP
application designers are advised to avoid mechanisms that can only
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 Format
This specification defines several RTCP packet types to carry a
variety of control information:
SR: Sender report, for transmission and reception statistics from
participants that are active senders
RR: Receiver report, for reception statistics from participants that
are not active senders
SDES: Source description items, including CNAME
BYE: Indicates end of participation
APP: Application specific functions
Each RTCP packet begins with a fixed part similar to that of RTP data
packets, followed by structured elements that may be of variable
length according to the packet type but always end on a 32-bit
boundary. The alignment requirement and a length field in the fixed
part are included to make RTCP packets "stackable". Multiple RTCP
packets may be concatenated without any intervening separators to
form a compound RTCP packet that is sent in a single packet of the
lower layer protocol, for example UDP. There is no explicit count of
individual RTCP packets in the compound packet since the lower layer
protocols are expected to provide an overall length to determine the
end of the compound packet.
Each individual RTCP packet in the compound packet may be processed
independently with no requirements upon the order or combination of
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 as
bandwidth constraints will allow to maximize the resolution of
the statistics, therefore each periodically transmitted
compound RTCP packet should include a report packet.
o New receivers need to receive the CNAME for a source as soon
as possible to identify the source and to begin associating
media for purposes such as lip-sync, so each compound RTCP
packet should also include the SDES CNAME.
o The number of packet types that may appear first in the
compound packet should be limited to increase the number of
constant bits in the first word and the probability of
successfully validating RTCP packets against misaddressed RTP
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 least
two individual packets, with the following format recommended:
Encryption prefix: If and only if the compound packet is to be
encrypted, it is prefixed by a random 32-bit quantity redrawn
for every compound packet transmitted.
SR or RR: The first RTCP packet in the compound packet must always
be a report packet to facilitate header validation as described
in Appendix A.2. This is true even if no data has been sent nor
received, in which case an empty RR is sent, and even if the
only other RTCP packet in the compound packet is a BYE.
Additional RRs: If the number of sources for which reception
statistics are being reported exceeds 31, the number that will
fit into one SR or RR packet, then additional RR packets should
follow the initial report packet.
SDES: An SDES packet containing a CNAME item must be included in
each compound RTCP packet. Other source description items may
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 be
defined, may follow in any order, except that BYE should be the
last packet sent with a given SSRC/CSRC. Packet types may appear
more than once.
It is advisable for translators and mixers to combine individual RTCP
packets from the multiple sources they are forwarding into one
compound packet whenever feasible in order to amortize the packet
overhead (see Section 7). An example RTCP compound packet as might be
produced by a mixer is shown in Fig. 1. If the overall length of a
compound packet would exceed the maximum transmission unit (MTU) of
the network path, it may be segmented into multiple shorter compound
packets to be transmitted in separate packets of the underlying
protocol. Note that each of the compound packets must begin with an
SR or RR packet.
An implementation may ignore incoming RTCP packets with types unknown
to it. Additional RTCP packet types may be registered with the
Internet Assigned Numbers Authority (IANA).
Schulzrinne, et al Standards Track [Page 18]
RFC 1889 RTP January 1996
6.2 RTCP Transmission Interval
if encrypted: random 32-bit integer
|
|[------- packet -------][----------- packet -----------][-packet-]
|
| receiver reports chunk chunk
V item 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/CSRC
Figure 1: Example of an RTCP compound packet
RTP is designed to allow an application to scale automatically over
session sizes ranging from a few participants to thousands. For
example, in an audio conference the data traffic is inherently self-
limiting because only one or two people will speak at a time, so with
multicast distribution the data rate on any given link remains
relatively constant independent of the number of participants.
However, the control traffic is not self-limiting. If the reception
reports from each participant were sent at a constant rate, the
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 to
an aggregate limit called the "session bandwidth" to be divided among
the participants. This bandwidth might be reserved and the limit
enforced by the network, or it might just be a reasonable share. The
session bandwidth may be chosen based or some cost or a priori
knowledge of the available network bandwidth for the session. It is
somewhat independent of the media encoding, but the encoding choice
may be limited by the session bandwidth. The session bandwidth
parameter is expected to be supplied by a session management
application when it invokes a media application, but media
applications may also set a default based on the single-sender data
bandwidth for the encoding selected for the session. The application
may also enforce bandwidth limits based on multicast scope rules or
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 that
is what the resource reservation system would need to know. The
application can also be expected to know which of these protocols are
in use. Link level headers are not included in the calculation since
the packet will be encapsulated with different link level headers as
it travels.
The control traffic should be limited to a small and known fraction
of the session bandwidth: small so that the primary function of the
transport protocol to carry data is not impaired; known so that the
control traffic can be included in the bandwidth specification given
to a resource reservation protocol, and so that each participant can
independently calculate its share. It is suggested that the fraction
of the session bandwidth allocated to RTCP be fixed at 5%. While the
value of this and other constants in the interval calculation is not
critical, all participants in the session must use the same values so
the same interval will be calculated. Therefore, these constants
should be fixed for a particular profile.
The algorithm described in Appendix A.7 was designed to meet the
goals outlined above. It calculates the interval between sending
compound RTCP packets to divide the allowed control traffic bandwidth
among the participants. This allows an application to provide fast
response for small sessions where, for example, identification of all
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 control
traffic bandwidth so that in sessions with a large number of
receivers but a small number of senders, newly joining
participants will more quickly receive the CNAME for the
sending sites.
o The calculated interval between RTCP packets is required to be
greater than a minimum of 5 seconds to avoid having bursts of
RTCP packets exceed the allowed bandwidth when the number of
participants is small and the traffic isn't smoothed according
to the law of large numbers.
o The interval between RTCP packets is varied randomly over the
range [0.5,1.5] times the calculated interval to avoid
unintended synchronization of all participants [10]. The first
RTCP packet sent after joining a session is also delayed by a
random variation of half the minimum RTCP interval in case the
application is started at multiple sites simultaneously, for
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 is
calculated, including all those received and sent, to
automatically adapt to changes in the amount of control
information carried.
This algorithm may be used for sessions in which all participants are
allowed to send. In that case, the session bandwidth parameter is the
product of the individual sender's bandwidth times the number of
participants, and the RTCP bandwidth is 5% of that.
6.2.1 Maintaining the number of session members
Calculation of the RTCP packet interval depends upon an estimate of
the number of sites participating in the session. New sites are added
to the count when they are heard, and an entry for each is created in
a table indexed by the SSRC or CSRC identifier (see Section 8.2) to
keep track of them. New entries may not be considered valid until
multiple packets carrying the new SSRC have been received (see
Appendix A.1). Entries may be deleted from the table when an RTCP BYE
packet with the corresponding SSRC identifier is received.
A participant may mark another site inactive, or delete it if not yet
valid, if no RTP or RTCP packet has been received for a small number
of RTCP report intervals (5 is suggested). This provides some
robustness against packet loss. All sites must calculate roughly the
same value for the RTCP report interval in order for this timeout to
work properly.
Once a site has been validated, then if it is later marked inactive
the state for that site should still be retained and the site should
continue to be counted in the total number of sites sharing RTCP
bandwidth for a period long enough to span typical network
partitions. This is to avoid excessive traffic, when the partition
heals, due to an RTCP report interval that is too small. A timeout of
30 minutes is suggested. Note that this is still larger than 5 times
the largest value to which the RTCP report interval is expected to
usefully scale, about 2 to 5 minutes.
6.2.2 Allocation of source description bandwidth
This specification defines several source description (SDES) items in
addition to the mandatory CNAME item, such as NAME (personal name)
and EMAIL (email address). It also provides a means to define new
application-specific RTCP packet types. Applications should exercise
caution in allocating control bandwidth to this additional
information because it will slow down the rate at which reception
reports and CNAME are sent, thus impairing the performance of the
protocol. It is recommended that no more than 20% of the RTCP
Schulzrinne, et al Standards Track [Page 21]
RFC 1889 RTP January 1996
bandwidth allocated to a single participant be used to carry the
additional information. Furthermore, it is not intended that all
SDES items should be included in every application. Those that are
included should be assigned a fraction of the bandwidth according to
their utility. Rather than estimate these fractions dynamically, it
is recommended that the percentages be translated statically into
report interval counts based on the typical length of an item.
For example, an application may be designed to send only CNAME, NAME
and EMAIL and not any others. NAME might be given much higher
priority than EMAIL because the NAME would be displayed continuously
in the application's user interface, whereas EMAIL would be displayed
only when requested. At every RTCP interval, an RR packet and an SDES
packet with the CNAME item would be sent. For a small session
operating at the minimum interval, that would be every 5 seconds on
the average. Every third interval (15 seconds), one extra item would
be included in the SDES packet. Seven out of eight times this would
be the NAME item, and every eighth time (2 minutes) it would be the
EMAIL item.
When multiple applications operate in concert using cross-application
binding through a common CNAME for each participant, for example in a
multimedia conference composed of an RTP session for each medium, the
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 Reports
RTP receivers provide reception quality feedback using RTCP report
packets which may take one of two forms depending upon whether or not
the receiver is also a sender. The only difference between the sender
report (SR) and receiver report (RR) forms, besides the packet type
code, is that the sender report includes a 20-byte sender information
section for use by active senders. The SR is issued if a site has
sent any data packets during the interval since issuing the last
report or the previous one, otherwise the RR is issued.
Both the SR and RR forms include zero or more reception report
blocks, one for each of the synchronization sources from which this
receiver has received RTP data packets since the last report. Reports
are not issued for contributing sources listed in the CSRC list. Each
reception report block provides statistics about the data received
from the particular source indicated in that block. Since a maximum
of 31 reception report blocks will fit in an SR or RR packet,
additional RR packets may be stacked after the initial SR or RR
packet as needed to contain the reception reports for all sources
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 may
be extended in a profile-specific manner if an application requires
additional feedback information, and how the reports may be used.
Details of reception reporting by translators and mixers is given in
Section 7.
6.3.1 SR: Sender report RTCP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP timestamp, most significant word | sender
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| 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) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender report packet consists of three sections, possibly
followed by a fourth profile-specific extension section if defined.
The first section, the header, is 8 octets long. The fields have the
following meaning:
Schulzrinne, et al Standards Track [Page 23]
RFC 1889 RTP January 1996
version (V): 2 bits
Identifies the version of RTP, which is the same in RTCP packets
as in RTP data packets. The version defined by this
specification is two (2).
padding (P): 1 bit
If the padding bit is set, this RTCP packet contains some
additional padding octets at the end which are not part of the
control information. The last octet of the padding is a count of
how many padding octets should be ignored. Padding may be needed
by some encryption algorithms with fixed block sizes. In a
compound RTCP packet, padding should only be required on the
last individual packet because the compound packet is encrypted
as a whole.
reception report count (RC): 5 bits
The number of reception report blocks contained in this packet.
A value of zero is valid.
packet type (PT): 8 bits
Contains the constant 200 to identify this as an RTCP SR packet.
length: 16 bits
The length of this RTCP packet in 32-bit words minus one,
including the header and any padding. (The offset of one makes
zero a valid length and avoids a possible infinite loop in
scanning a compound RTCP packet, while counting 32-bit words
avoids a validity check for a multiple of 4.)
SSRC: 32 bits
The synchronization source identifier for the originator of this
SR packet.
The second section, the sender information, is 20 octets long and is
present in every sender report packet. It summarizes the data
transmissions from this sender. The fields have the following
meaning:
NTP timestamp: 64 bits
Indicates the wallclock time when this report was sent so that
it may be used in combination with timestamps returned in
reception reports from other receivers to measure round-trip
propagation to those receivers. Receivers should expect that the
measurement accuracy of the timestamp may be limited to far less
than the resolution of the NTP timestamp. The measurement
uncertainty of the timestamp is not indicated as it may not be
known. A sender that can keep track of elapsed time but has no
notion of wallclock time may use the elapsed time since joining
Schulzrinne, et al Standards Track [Page 24]
RFC 1889 RTP January 1996
the session instead. This is assumed to be less than 68 years,
so the high bit will be zero. It is permissible to use the
sampling clock to estimate elapsed wallclock time. A sender that
has no notion of wallclock or elapsed time may set the NTP
timestamp to zero.
RTP timestamp: 32 bits
Corresponds to the same time as the NTP timestamp (above), but
in the same units and with the same random offset as the RTP
timestamps in data packets. This correspondence may be used for
intra- and inter-media synchronization for sources whose NTP
timestamps are synchronized, and may be used by media-
independent receivers to estimate the nominal RTP clock
frequency. Note that in most cases this timestamp will not be
equal to the RTP timestamp in any adjacent data packet. Rather,
it is calculated from the corresponding NTP timestamp using the
relationship between the RTP timestamp counter and real time as
maintained by periodically checking the wallclock time at a
sampling instant.
sender's packet count: 32 bits
The total number of RTP data packets transmitted by the sender
since starting transmission up until the time this SR packet was
generated. The count is reset if the sender changes its SSRC
identifier.
sender's octet count: 32 bits
The total number of payload octets (i.e., not including header
or padding) transmitted in RTP data packets by the sender since
starting transmission up until the time this SR packet was
generated. The count is reset if the sender changes its SSRC
identifier. This field can be used to estimate the average
payload data rate.
The third section contains zero or more reception report blocks
depending on the number of other sources heard by this sender since
the last report. Each reception report block conveys statistics on
the reception of RTP packets from a single synchronization source.
Receivers do not carry over statistics when a source changes its SSRC
identifier due to a collision. These statistics are:
SSRC_n (source identifier): 32 bits
The SSRC identifier of the source to which the information in
this reception report block pertains.
fraction lost: 8 bits
The fraction of RTP data packets from source SSRC_n lost since
the previous SR or RR packet was sent, expressed as a fixed
Schulzrinne, et al Standards Track [Page 25]
RFC 1889 RTP January 1996
point number with the binary point at the left edge of the
field. (That is equivalent to taking the integer part after
multiplying the loss fraction by 256.) This fraction is defined
to be the number of packets lost divided by the number of
packets expected, as defined in the next paragraph. An
implementation is shown in Appendix A.3. If the loss is negative
due to duplicates, the fraction lost is set to zero. Note that a
receiver cannot tell whether any packets were lost after the
last one received, and that there will be no reception report
block issued for a source if all packets from that source sent
during the last reporting interval have been lost.
cumulative number of packets lost: 24 bits
The total number of RTP data packets from source SSRC_n that
have been lost since the beginning of reception. This number is
defined to be the number of packets expected less the number of
packets actually received, where the number of packets received
includes any which are late or duplicates. Thus packets that
arrive late are not counted as lost, and the loss may be
negative if there are duplicates. The number of packets
expected is defined to be the extended last sequence number
received, as defined next, less the initial sequence number
received. This may be calculated as shown in Appendix A.3.
extended highest sequence number received: 32 bits
The low 16 bits contain the highest sequence number received in
an RTP data packet from source SSRC_n, and the most significant
16 bits extend that sequence number with the corresponding count
of sequence number cycles, which may be maintained according to
the algorithm in Appendix A.1. Note that different receivers
within the same session will generate different extensions to
the sequence number if their start times differ significantly.
interarrival jitter: 32 bits
An estimate of the statistical variance of the RTP data packet
interarrival time, measured in timestamp units and expressed as
an unsigned integer. The interarrival jitter J is defined to be
the mean deviation (smoothed absolute value) of the difference D
in packet spacing at the receiver compared to the sender for a
pair of packets. As shown in the equation below, this is
equivalent to the difference in the "relative transit time" for
the two packets; the relative transit time is the difference
between a packet's RTP timestamp and the receiver's clock at the
time of arrival, measured in the same units.
Schulzrinne, et al Standards Track [Page 26]
RFC 1889 RTP January 1996
If Si is the RTP timestamp from packet i, and Ri is the time of
arrival in RTP timestamp units for packet i, then for two packets i
and j, D may be expressed as
D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)
The interarrival jitter is calculated continuously as each data
packet i is received from source SSRC_n, using this difference D for
that packet and the previous packet i-1 in order of arrival (not
necessarily in sequence), according to the formula
J=J+(|D(i-1,i)|-J)/16
Whenever a reception report is issued, the current value of J is
sampled.
The jitter calculation is prescribed here to allow profile-
independent monitors to make valid interpretations of reports coming
from different implementations. This algorithm is the optimal first-
order estimator and the gain parameter 1/16 gives a good noise
reduction ratio while maintaining a reasonable rate of convergence
[11]. A sample implementation is shown in Appendix A.8.
last SR timestamp (LSR): 32 bits
The middle 32 bits out of 64 in the NTP timestamp (as explained
in Section 4) received as part of the most recent RTCP sender
report (SR) packet from source SSRC_n. If no SR has been
received yet, the field is set to zero.
delay since last SR (DLSR): 32 bits
The delay, expressed in units of 1/65536 seconds, between
receiving the last SR packet from source SSRC_n and sending this
reception report block. If no SR packet has been received yet
from SSRC_n, the DLSR field is set to zero.
Let SSRC_r denote the receiver issuing this receiver report. Source
SSRC_n can compute the round propagation delay to SSRC_r by recording
the time A when this reception report block is received. It
calculates the total round-trip time A-LSR using the last SR
timestamp (LSR) field, and then subtracting this field to leave the
round-trip propagation delay as (A- LSR - DLSR). This is illustrated
in Fig. 2.
This may be used as an approximate measure of distance to cluster
receivers, although some links have very asymmetric delays.
Schulzrinne, et al Standards Track [Page 27]
RFC 1889 RTP January 1996
6.3.2 RR: Receiver report RTCP packet
[10 Nov 1995 11:33:25.125] [10 Nov 1995 11:33:36.5]
n SR(n) A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992016.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
A 0xb710:8000 (46864.500 s)
DLSR -0x0005:4000 ( 5.250 s)
LSR -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x 6:2000 ( 6.125 s)
Figure 2: Example for round-trip time computation
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=RR=201 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| 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) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Schulzrinne, et al Standards Track [Page 28]
RFC 1889 RTP January 1996
The format of the receiver report (RR) packet is the same as that of
the SR packet except that the packet type field contains the constant
201 and the five words of sender information are omitted (these are
the NTP and RTP timestamps and sender's packet and octet counts). The
remaining fields have the same meaning as for the SR packet.
An empty RR packet (RC = 0) is put at the head of a compound RTCP
packet when there is no data transmission or reception to report.
6.3.3 Extending the sender and receiver reports
A profile should define profile- or application-specific extensions
to the sender report and receiver if there is additional information
that should be reported regularly about the sender or receivers. This
method should be used in preference to defining another RTCP packet
type because it requires less overhead:
o fewer octets in the packet (no RTCP header or SSRC field);
o simpler and faster parsing because applications running under
that profile would be programmed to always expect the extension
fields in the directly accessible location after the reception
reports.
If additional sender information is required, it should be included
first in the extension for sender reports, but would not be present
in receiver reports. If information about receivers is to be
included, that data may be structured as an array of blocks parallel
to the existing array of reception report blocks; that is, the number
of blocks would be indicated by the RC field.
6.3.4 Analyzing sender and receiver reports
It is expected that reception quality feedback will be useful not
only for the sender but also for other receivers and third-party
monitors. The sender may modify its transmissions based on the
feedback; receivers can determine whether problems are local,
regional or global; network managers may use profile-independent
monitors that receive only the RTCP packets and not the corresponding
RTP data packets to evaluate the performance of their networks for
multicast distribution.
Cumulative counts are used in both the sender information and
receiver report blocks so that differences may be calculated between
any two reports to make measurements over both short and long time
periods, and to provide resilience against the loss of a report. The
difference between the last two reports received can be used to
estimate the recent quality of the distribution. The NTP timestamp is
Schulzrinne, et al Standards Track [Page 29]
RFC 1889 RTP January 1996
included so that rates may be calculated from these differences over
the interval between two reports. Since that timestamp is independent
of the clock rate for the data encoding, it is possible to implement
encoding- and profile-independent quality monitors.
An example calculation is the packet loss rate over the interval
between two reception reports. The difference in the cumulative
number of packets lost gives the number lost during that interval.
The difference in the extended last sequence numbers received gives
the number of packets expected during the interval. The ratio of
these two is the packet loss fraction over the interval. This ratio
should equal the fraction lost field if the two reports are
consecutive, but otherwise not. The loss rate per second can be
obtained by dividing the loss fraction by the difference in NTP
timestamps, expressed in seconds. The number of packets received is
the number of packets expected minus the number lost. The number of
packets expected may also be used to judge the statistical validity
of any loss estimates. For example, 1 out of 5 packets lost has a
lower significance than 200 out of 1000.
From the sender information, a third-party monitor can calculate the
average payload data rate and the average packet rate over an
interval without receiving the data. Taking the ratio of the two
gives the average payload size. If it can be assumed that packet loss
is independent of packet size, then the number of packets received by
a particular receiver times the average payload size (or the
corresponding packet size) gives the apparent throughput available to
that receiver.
In addition to the cumulative counts which allow long-term packet
loss measurements using differences between reports, the fraction
lost field provides a short-term measurement from a single report.
This becomes more important as the size of a session scales up enough
that reception state information might not be kept for all receivers
or the interval between reports becomes long enough that only one
report might have been received from a particular receiver.
The interarrival jitter field provides a second short-term measure of
network congestion. Packet loss tracks persistent congestion while
the jitter measure tracks transient congestion. The jitter measure
may indicate congestion before it leads to packet loss. Since the
interarrival jitter field is only a snapshot of the jitter at the
time of a report, it may be necessary to analyze a number of reports
from one receiver over time or from multiple receivers, e.g., within
a single network.
Schulzrinne, et al Standards Track [Page 30]
RFC 1889 RTP January 1996
6.4 SDES: Source description RTCP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=SDES=202 | length | header
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC/CSRC_1 | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC/CSRC_2 | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SDES packet is a three-level structure composed of a header and
zero or more chunks, each of of which is composed of items describing
the source identified in that chunk. The items are described
individually in subsequent sections.
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).
packet type (PT): 8 bits
Contains the constant 202 to identify this as an RTCP SDES
packet.
source count (SC): 5 bits
The number of SSRC/CSRC chunks contained in this SDES packet. A
value of zero is valid but useless.
Each chunk consists of an SSRC/CSRC identifier followed by a list of
zero or more items, which carry information about the SSRC/CSRC. Each
chunk starts on a 32-bit boundary. Each item consists of an 8-bit
type field, an 8-bit octet count describing the length of the text
(thus, not including this two-octet header), and the text itself.
Note that the text can be no longer than 255 octets, but this is
consistent with the need to limit RTCP bandwidth consumption.
The text is encoded according to the UTF-2 encoding specified in
Annex F of ISO standard 10646 [12,13]. This encoding is also known as
UTF-8 or UTF-FSS. It is described in "File System Safe UCS
Transformation Format (FSS_UTF)", X/Open Preliminary Specification,
Document Number P316 and Unicode Technical Report #4. US-ASCII is a
subset of this encoding and requires no additional encoding. The
Schulzrinne, et al Standards Track [Page 31]
RFC 1889 RTP January 1996
presence of multi-octet encodings is indicated by setting the most
significant bit of a character to a value of one.
Items are contiguous, i.e., items are not individually padded to a
32-bit boundary. Text is not null terminated because some multi-octet
encodings include null octets. The list of items in each chunk is
terminated by one or more null octets, the first of which is
interpreted as an item type of zero to denote the end of the list,
and the remainder as needed to pad until the next 32-bit boundary. A
chunk with zero items (four null octets) is valid but useless.
End systems send one SDES packet containing their own source
identifier (the same as the SSRC in the fixed RTP header). A mixer
sends one SDES packet containing a chunk for each contributing source
from which it is receiving SDES information, or multiple complete
SDES packets in the format above if there are more than 31 such
sources (see Section 7).
The SDES items currently defined are described in the next sections.
Only the CNAME item is mandatory. Some items shown here may be useful
only for particular profiles, but the item types are all assigned
from one common space to promote shared use and to simplify profile-
independent applications. Additional items may be defined in a
profile by registering the type numbers with IANA.
6.4.1 CNAME: Canonical end-point identifier SDES item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CNAME identifier has the following properties:
o Because the randomly allocated SSRC identifier may change if a
conflict is discovered or if a program is restarted, the CNAME
item is required to provide the binding from the SSRC
identifier to an identifier for the source that remains
constant.
o Like the SSRC identifier, the CNAME identifier should also be
unique among all participants within one RTP session.
o To provide a binding across multiple media tools used by one
participant in a set of related RTP sessions, the CNAME should
be fixed for that participant.
Schulzrinne, et al Standards Track [Page 32]
RFC 1889 RTP January 1996
o To facilitate third-party monitoring, the CNAME should be
suitable for either a program or a person to locate the source.
Therefore, the CNAME should be derived algorithmically and not
entered manually, when possible. To meet these requirements, the
following format should be used unless a profile specifies an
alternate syntax or semantics. The CNAME item should have the format
"user@host", or "host" if a user name is not available as on single-
user systems. For both formats, "host" is either the fully qualified
domain name of the host from which the real-time data originates,
formatted according to the rules specified in RFC 1034 [14], RFC 1035
[15] and Section 2.1 of RFC 1123 [16]; or the standard ASCII
representation of the host's numeric address on the interface used
for the RTP communication. For example, the standard ASCII
representation of an IP Version 4 address is "dotted decimal", also
known as dotted quad. Other address types are expected to have ASCII
representations that are mutually unique. The fully qualified domain
name is more convenient for a human observer and may avoid the need
to send a NAME item in addition, but it may be difficult or
impossible to obtain reliably in some operating environments.
Applications that may be run in such environments should use the
ASCII representation of the address instead.
Examples are "doe@sleepy.megacorp.com" or "doe@192.0.2.89" for a
multi-user system. On a system with no user name, examples would be
"sleepy.megacorp.com" or "192.0.2.89".
The user name should be in a form that a program such as "finger" or
"talk" could use, i.e., it typically is the login name rather than
the personal name. The host name is not necessarily identical to the
one in the participant's electronic mail address.
This syntax will not provide unique identifiers for each source if an
application permits a user to generate multiple sources from one
host. Such an application would have to rely on the SSRC to further
identify the source, or the profile for that application would have
to specify additional syntax for the CNAME identifier.
If each application creates its CNAME independently, the resulting
CNAMEs may not be identical as would be required to provide a binding
across multiple media tools belonging to one participant in a set of
related RTP sessions. If cross-media binding is required, it may be
necessary for the CNAME of each tool to be externally configured with
the same value by a coordination tool.
Application writers should be aware that private network address
assignments such as the Net-10 assignment proposed in RFC 1597 [17]
may create network addresses that are not globally unique. This would
Schulzrinne, et al Standards Track [Page 33]
RFC 1889 RTP January 1996
lead to non-unique CNAMEs if hosts with private addresses and no
direct IP connectivity to the public Internet have their RTP packets
forwarded to the public Internet through an RTP-level translator.
(See also RFC 1627 [18].) To handle this case, applications may
provide a means to configure a unique CNAME, but the burden is on the
translator to translate CNAMEs from private addresses to public
addresses if necessary to keep private addresses from being exposed.
6.4.2 NAME: User name SDES item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the real name used to describe the source, e.g., "John Doe,
Bit Recycler, Megacorp". It may be in any form desired by the user.
For applications such as conferencing, this form of name may be the
most desirable for display in participant lists, and therefore might
be sent most frequently of those items other than CNAME. Profiles may
establish such priorities. The NAME value is expected to remain
constant at least for the duration of a session. It should not be
relied upon to be unique among all participants in the session.
6.4.3 EMAIL: Electronic mail address SDES item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMAIL=3 | length | email address of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The email address is formatted according to RFC 822 [19], for
example, "John.Doe@megacorp.com". The EMAIL value is expected to
remain constant for the duration of a session.
6.4.4 PHONE: Phone number SDES item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHONE=4 | length | phone number of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The phone number should be formatted with the plus sign replacing the
international access code. For example, "+1 908 555 1212" for a
number in the United States.
Schulzrinne, et al Standards Track [Page 34]
RFC 1889 RTP January 1996
6.4.5 LOC: Geographic user location SDES item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC=5 | length | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Depending on the application, different degrees of detail are
appropriate for this item. For conference applications, a string like
"Murray Hill, New Jersey" may be sufficient, while, for an active
badge system, strings like "Room 2A244, AT&T BL MH" might be
appropriate. The degree of detail is left to the implementation
and/or user, but format and content may be prescribed by a profile.
The LOC value is expected to remain constant for the duration of a
session, except for mobile hosts.
6.4.6 TOOL: Application or tool name SDES item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOOL=6 | length | name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A string giving the name and possibly version of the application
generating the stream, e.g., "videotool 1.2". This information may be
useful for debugging purposes and is similar to the Mailer or Mail-
System-Version SMTP headers. The TOOL value is expected to remain
constant for the duration of the session.
6.4.7 NOTE: Notice/status SDES item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NOTE=7 | length | note about the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following semantics are suggested for this item, but these or
other semantics may be explicitly defined by a profile. The NOTE item
is intended for transient messages describing the current state of
the source, e.g., "on the phone, can't talk". Or, during a seminar,
this item might be used to convey the title of the talk. It should be
used only to carry exceptional information and should not be included
routinely by all participants because this would slow down the rate
at which reception reports and CNAME are sent, thus impairing the
performance of the protocol. In particular, it should not be included
Schulzrinne, et al Standards Track [Page 35]
RFC 1889 RTP January 1996
as an item in a user's configuration file nor automatically generated
as in a quote-of-the-day.
Since the NOTE item may be important to display while it is active,
the rate at which other non-CNAME items such as NAME are transmitted
might be reduced so that the NOTE item can take that part of the RTCP
bandwidth. When the transient message becomes inactive, the NOTE item
should continue to be transmitted a few times at the same repetition
rate but with a string of length zero to signal the receivers.
However, receivers should also consider the NOTE item inactive if it
is not received for a small multiple of the repetition rate, or
perhaps 20-30 RTCP intervals.
6.4.8 PRIV: Private extensions SDES item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIV=8 | length | prefix length | prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This item is used to define experimental or application-specific SDES
extensions. The item contains a prefix consisting of a length-string
pair, followed by the value string filling the remainder of the item
and carrying the desired information. The prefix length field is 8
bits long. The prefix string is a name chosen by the person defining
the PRIV item to be unique with respect to other PRIV items this
application might receive. The application creator might choose to
use the application name plus an additional subtype identification if
needed. Alternatively, it is recommended that others choose a name
based on the entity they represent, then coordinate the use of the
name within that entity.
Note that the prefix consumes some space within the item's total
length of 255 octets, so the prefix should be kept as short as
possible. This facility and the constrained RTCP bandwidth should not
be overloaded; it is not intended to satisfy all the control
communication requirements of all applications.
SDES PRIV prefixes will not be registered by IANA. If some form of
the PRIV item proves to be of general utility, it should instead be
assigned a regular SDES item type registered with IANA so that no
prefix is required. This simplifies use and increases transmission
efficiency.
Schulzrinne, et al Standards Track [Page 36]
RFC 1889 RTP January 1996
6.5 BYE: Goodbye RTCP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| length | reason for leaving ... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BYE packet indicates that one or more sources are no longer
active.
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).
packet type (PT): 8 bits
Contains the constant 203 to identify this as an RTCP BYE
packet.
source count (SC): 5 bits
The number of SSRC/CSRC identifiers included in this BYE packet.
A count value of zero is valid, but useless.
If a BYE packet is received by a mixer, the mixer forwards the BYE
packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts
down, it should send a BYE packet listing all contributing sources it
handles, as well as its own SSRC identifier. Optionally, the BYE
packet may include an 8-bit octet count followed by that many octets
of text indicating the reason for leaving, e.g., "camera malfunction"
or "RTP loop detected". The string has the same encoding as that
described for SDES. If the string fills the packet to the next 32-bit
boundary, the string is not null terminated. If not, the BYE packet
is padded with null octets.
Schulzrinne, et al Standards Track [Page 37]
RFC 1889 RTP January 1996
6.6 APP: Application-defined RTCP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The APP packet is intended for experimental use as new applications
and new features are developed, without requiring packet type value
registration. APP packets with unrecognized names should be ignored.
After testing and if wider use is justified, it is recommended that
each APP packet be redefined without the subtype and name fields and
registered with the Internet Assigned Numbers Authority using an RTCP
packet type.
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).