WDIFF

draft-ietf-avt-rtp-new-00.txt --> draft-ietf-avt-rtp-new-01.txt

Internet Engineering Task Force Audio/Video Transport Working Group
Internet Draft Schulzrinne/Casner/Frederick/Jacobson
ietf-avt-rtp-new-00.txt
ietf-avt-rtp-new-01.txt Columbia U./Precept/Xerox/LBNL
December 5, 1997
Expires: June 5, U./Cisco/Xerox/LBNL
August 7, 1998
Expires: February 7, 1999

RTP: A Transport Protocol for Real-Time Applications

STATUS OF THIS MEMO

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress''.

To learn view the current status entire list of any Internet-Draft, current Internet-Drafts, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ds.internic.net ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.

ABSTRACT

This memorandum is a revision of RFC 1889 in preparation
for advancement from Proposed Standard to Draft Standard
status. Readers are encouraged to use the PostScript form
of this draft to see where changes from RFC 1889 are
marked by change bars. The revision process is not yet
complete; some changes which have been discussed and
tentatively accepted in meetings of the Audio/Video
Transport working group have not yet been incorporated
into this draft.

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

Schulzrinne/Casner/Frederick/Jacobson [Page 1]

Internet Draft RTP December 5, 1997 August 7, 1998

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.

This specification is a product of the Audio/Video Transport working
group within the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing list
at rem-conf@es.net and/or the authors.

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

Resolution 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 Open Issues

[Note to multiple
destinations using multicast distribution if provided by the
underlying network.

Note that RTP itself does not provide any mechanism RFC Editor: This section is to ensure timely
delivery or provide other quality-of-service guarantees, be deleted when this
draft is published as an RFC but relies
on lower-layer services is shown here for reference during
the Last Call.]

Readers are directed to do so. It does not guarantee delivery or
prevent out-of-order delivery, nor does it assume that Appendix B, Changes from RFC 1889, for a
listing of the underlying
network is reliable and delivers packets changes that have been made in sequence. this draft. The sequence
numbers included changes
are marked with change bars in RTP allow the receiver PostScript form of this draft.

The revisions in this draft are mostly complete for Working Group
last call; the open issues have been addressed:

o A fudge factor has been added to reconstruct the
sender's packet sequence, but sequence numbers might also be used RTCP unconditional
reconsideration algorithm to
determine compensate for the proper location of a packet, for example in video
decoding, without necessarily decoding packets in sequence.

While RTP fact that it
settles to a steady state bandwidth that is primarily designed below the desired
level.

o A new "bin" mechanism has been added to satisfy the needs algorithm for
sampled storaged of multi-
participant multimedia conferences, it SSRC identifiers to avoid a temporary
underestimate in group size when the group size is decreasing.

o The "reverse reconsideration" algorithm does not limited prevent the
group size estimate from incorrectly dropping to that
particular application. Storage zero for a
short time when most participants of continuous data, interactive
distributed simulation, active badge, and control and measurement
applications may also find RTP applicable. a large session leave at
once but some remain. This document defines RTP, consisting of two closely-linked parts: has just been noted as only a
secondary concern.

o Scaling of the real-time transport protocol (RTP), minimum RTCP interval inversely proportional to carry data that
the session bandwidth parameter has been added, but only in the
direction of smaller intervals for higher bandwidth. Scaling to
longer intervals for low bandwidths would cause a problem

Schulzrinne/Casner/Frederick/Jacobson [Page 2]

Internet Draft RTP December 5, 1997

real-time properties.

o the RTP control protocol (RTCP), to monitor the quality of
service and August 7, 1998

because this is an optional step. Some participants might be
timed out prematurely if they scaled to convey information about a longer interval while
others kept the participants in an
on-going session. nominal 5 seconds. The latter aspect benefit of RTCP may be sufficient
for "loosely controlled" sessions, i.e., where there is no
explicit membership control and set-up, but it is scaling
longer was not
necessarily intended to support all of an application's control
communication requirements. This functionality may considered great in any case.

o No change was specified for the jitter computation for media
with several packets with the same timestamp. There is not a
clear answer as to what should be fully done, or
partially subsumed by that any change
would make a separate session control protocol,
which is beyond significant improvement.

o As proposed without objection at the scope Los Angeles IETF,
definition of this document.

RTP represents a new style additional SDES items such as PHOTO URL and
NICKNAME will be deferred to subsequent registration through
IANA since that method has been established. This is in the
spirit of minimizing changes to the protocol following in the principles of
application level framing and integrated layer processing proposed by
Clark and Tennenhouse [1]. That is, RTP is intended transition
from Proposed to be malleable Draft.

o Nothing was added about allowing a translator to add its own
random offsets to provide the information required by a particular application sequence number and
will often be integrated into the application processing rather timestamp fields
because it would likely cause more trouble than
being implemented as a separate layer. RTP is a protocol framework
that is deliberately not complete. good.

1 Introduction

This document memorandum specifies those
functions expected to be common across all the applications for 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 would be appropriate. Unlike conventional on top of UDP
to make use of its multiplexing and checksum services; both protocols in which
additional functions might be accommodated by making
contribute parts of the transport protocol
more general or by adding an option mechanism 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 would require
parsing, 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 intended 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 tailored through modifications and/or
additions used to
determine the headers as needed. Examples are given proper location of a packet, for example in Sections
5.3 and 6.4.3.

Therefore, video
decoding, without necessarily decoding packets in addition sequence.

While RTP is primarily designed to this document, a complete specification satisfy the needs of
RTP for a multi-
participant multimedia conferences, it is not limited to that
particular application will require one or more companion
documents (see Section 12):

o a profile specification document, which defines a set application. Storage of
payload type codes continuous data, interactive

Schulzrinne/Casner/Frederick/Jacobson [Page 3]

Internet Draft RTP August 7, 1998

distributed simulation, active badge, and their mapping to payload formats (e.g.,
media encodings). A profile control and measurement
applications may also define extensions or
modifications to find RTP applicable.

This document defines RTP, consisting of two closely-linked parts:

o the real-time transport protocol (RTP), to carry data that are specific has
real-time properties.

o the RTP control protocol (RTCP), to a particular class monitor the quality of
applications. Typically
service and to convey information about the participants in an application will operate under only
one profile. A profile
on-going session. The latter aspect of RTCP may be sufficient
for audio "loosely controlled" sessions, i.e., where there is no
explicit membership control and video data set-up, but it is not
necessarily intended to support all of an application's control
communication requirements. This functionality may be found in
the companion RFC 1890.

o payload format specification documents, which define how a
particular payload, such as an audio fully or video encoding,
partially subsumed by a separate session control protocol,
which is to
be carried in RTP.

A discussion beyond the scope of real-time services and algorithms for their
implementation as well as background discussion on some 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
design decisions can is intended to be found in [2].

Several RTP applications, both experimental malleable
to provide the information required by a particular application and commercial, have

Schulzrinne/Casner/Frederick/Jacobson [Page 3]

Internet Draft RTP December 5, 1997

already been
will often be integrated into the application processing rather than
being 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 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 full
potential demand applications 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-
time services on the Internet and other network services.

1.1 Changes

Most of this draft is identical to RFC 1889. The changes are listed
below and are marked with change bars which
RTP would be appropriate. Unlike conventional protocols in which
additional functions might be accommodated by making the PostScript form of this
draft. This section may become an appendix when the draft is
published as protocol
more general or by adding an updated RFC, but it option mechanism that would require
parsing, RTP is included here at the front of
the document at this point intended to be tailored through modifications and/or
additions to encourage feedback on these changes.

o The algorithm for calculating the RTCP transmission interval
specified headers as needed. Examples are given in Sections 6.2 and 6.3
5.3 and illustrated 6.4.3.

Therefore, in Appendix
A.7 is augmented to include "reconsideration" addition to minimize
transmission over the intended rate when many participants join this document, a session simultaneously, and "reverse reconsideration" to
reduce the incidence and duration of false participant timeouts
when the number complete specification of participants drops rapidly.

o
RTP for a particular application will require one or more companion
documents (see Section 6.3.7 specifies new rules controlling when an RTCP BYE
packet should be sent in order to avoid 12):

o a flood of packets when
many participants leave profile specification document, which defines a session simultaneously. Sections 7.2
and 7.3 specify that translators set of
payload type codes and mixers should send BYE
packets for the sources they their mapping to payload formats (e.g.,
media encodings). A profile may also define extensions or
modifications to RTP that are no longer forwarding.

o An algorithm is specified in Sections 6.3.3 and 6.3.4 specific to allow
storage of only a sampling particular class of the participants' SSRC
identifiers to allow scaling to very large sessions.

o Rule changes
applications. Typically an application will operate under only
one profile. A profile for layered encodings are defined in Sections
2.4, 6.3.9, 8.3 audio and 10.

o An indentation bug video data may be found in
the companion RFC 1889 printing of the pseudo-code
for the collision detection and resolution algorithm in Section
8.2 1890.

o payload format specification documents, which define how a
particular payload, such as an audio or video encoding, is corrected, and the algorithm has been modified to remove
the restriction that both RTP and RTCP must be sent from the
same source port number.

o For unicast RTP sessions, distinct port pairs may
be used for carried in RTP.

Schulzrinne/Casner/Frederick/Jacobson [Page 4]

Internet Draft RTP December 5, 1997

the two ends (Sections 3 August 7, 1998

A discussion of real-time services and 7.1).

o It is specified that a receiver MUST ignore packets with
payload types it does not understand.

o The reference algorithms for their
implementation as well as background discussion on some of the UTF-8 character set was changed RTP
design decisions can be found in [2].

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2044.

o Small clarifications 2119 [3] and
indicate requirement levels for compliant RTP implementations.

2 RTP Use Scenarios

The following sections describe some aspects of the text have been made in several
places in response to questions from readers. In particular:

-A definition for "RTP media type" is given in Section 3 use of RTP. The
examples were chosen to
allow illustrate the explanation basic operation of multiplexing RTP sessions in Section
5.2
applications using RTP, not to limit what RTP may be more clear regarding the multiplexing of multiple
media.

-The description used for. In
these examples, RTP is carried on top of IP and UDP, and follows the session bandwidth parameter is expanded
in Section 6.2.

-The method for padding RTCP packets is clarified in Section
6.4.

-The method
conventions established by the profile for terminating audio and padding a sequence of SDES
items is clarified in Section 6.5.

1.2 Open Issues

The revisions video specified
in this draft are not yet complete; first, there are
some open issues regarding the changes that have been made:

o The RTCP timer reconsideration algorithm settles to a steady
state bandwidth that is below companion RFC 1890 (updated by Internet-Draft draft-ietf-avt-
profile-new ).

2.1 Simple Multicast Audio Conference

A working group of the desired level. Can IETF meets to discuss the
algorithm compensate for this latest protocol
draft, using a fudge factor?

o The algorithm for sampled storaged of SSRC identifiers results
in a temporary underestimate in group size (and an increase in the RTCP rate) by a factor IP multicast services of 1/2 or more when the group size
is decreasing such that the mask size also decreases. This may
require Internet for voice
communications. Through some allocation mechanism to compensate.

o The "reverse reconsideration" algorithm does not prevent the working group size estimate from incorrectly dropping to zero for
chair obtains a
short time when most participants multicast group address and pair of a large session leave at
once but some remain. The algorithm does make ports. One port
is used for audio data, and the estimate
return other is used for control (RTCP)
packets. This address and port information is distributed to the correct value more rapidly. It
intended participants. If privacy is desired, the data and control
packets may be possible to
use a filter to slow the decrease encrypted as specified in the estimate and prevent
this problem, but that would Section 9.1, in which case
an encryption key must also slow down be generated and distributed. The exact
details of these allocation and distribution mechanisms are beyond
the increase 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
estimate encoding during a
conference, for simultaneous joins, which example, to accommodate a new participant that is
connected through a problem. 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

Schulzrinne/Casner/Frederick/Jacobson [Page 5]

Internet Draft RTP December 5, 1997

incorrect drop to zero may be deemed only a secondary concern.

Second, there are also some changes which have been discussed August 7, 1998

and
tentatively accepted a sequence number that allow the receivers to reconstruct the
timing produced by the source, so that in meetings 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 Audio/Video Transport working group have not yet been incorporated into this draft:

o Allowing RTCP sender join and receiver bandwidths leave during the
conference, it is useful to be separate
parameters know who is participating at any moment
and how well they are receiving the audio data. For that purpose,
each instance of the session rather than audio application in the conference periodically
multicasts a strict percentage reception report plus the name of its user on the session bandwidth. RTCP
(control) port. The defaults would retain reception report indicates how well the current
values of 1.25%
speaker is being received and 3.75%. This change would allow rate- may be used to control adaptive applications
encodings. In addition to set an RTCP bandwidth consistent with
a "typical" data bandwidth that is lower than the maximum
bandwidth specified by the session bandwidth parameter. It
would user name, other identifying
information may also allow RTCP reception reports to be turned off
entirely for operation on unidirectional links.
Correspondingly, the text requiring transmission of RTCP for
multicast sessions needs to be generalized.

o Scaling the minimum RTCP interval inversely proportional included subject to
the session control bandwidth parameter:

-to a larger value to help reduce limits.
A site sends the spike size on a step join RTCP BYE packet (Section 6.6) when access links are slow (and it leaves the session bandwidth is
therefore low);

-to provide sufficient time for a packet to arrive for
conditional reconsideration;

-to
conference.

2.2 Audio and Video Conference

If both audio and video media are used in a smaller value for high-rate multicast conference, they are
transmitted as separate RTP sessions to allow RTCP packets are transmitted for faster inter-media synchronization. Since the simultaneous
join flood
each medium using two different UDP port pairs and/or multicast
addresses. There is largely a function of the ratio of network
delays to no direct coupling at the minimum interval, RTP level between the value
audio and video sessions, except that a user participating in both
sessions should not be scaled
much below use the current 5 second minimum same distinguished (canonical) name in the
RTCP packets for receivers.
However, senders could both so that the sessions can be allowed associated.

One motivation for this separation is to transmit a higher RTCP
bandwidth while still using the 5 second value when computing allow some participants in
the interval for timeouts conference to avoid timing out receivers. A
smaller value receive only one medium if they choose. Further
explanation is also appropriate for unicast sessions.

o The text should consistently use the terms MUST, SHOULD, MAY
as defined given in RFC 2119.

Third, since Section 5.2. Despite the publication separation,
synchronized playback of RFC 1889, a source's audio and video can be achieved
using timing information carried in the following changes RTCP packets for both
sessions.

2.3 Mixers and Translators

So far, we have
been suggested but not yet discussed within the working group:

o For assumed that all sites want to receive media with several packets with data in
the same timestamp, the
jitter computation should format. However, this may not always be done only for appropriate.
Consider the case where participants in one packet (the
first?). 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

Schulzrinne/Casner/Frederick/Jacobson [Page 6]

Internet Draft RTP December 5, 1997

o Define August 7, 1998

audio encoding to a photo URL item in SDES, which lower-bandwidth one and forwards the lower-
bandwidth packet stream across the low-speed link. These packets
might be constrained unicast to
use by senders only. Such an addition could cause severe web
server overload by triggering many simultaneous requests if
used in a large single recipient or multicast session.

o on a different
address to multiple recipients. The specification of the NTP timestamp in RTP header includes a means for
mixers to identify the RTCP SR section
says sources that when "relative" NTP timestamps are used they should contributed to a mixed packet so
that correct talker indication can be based on elapsed time from provided at the start receivers.

Some of the session.
However, if the start times for intended participants in the audio and video sessions
are conference may be
connected with high bandwidth links but might not the same, then the NTP timestamps won't be usable for
synchronization. Should the base directly
reachable via IP multicast. For example, they might be changed to "system uptime,"
and if so, how should behind an
application-level firewall that be defined?

o The padding mechanism for RTCP packets is will not exactly the same
as for RTP let any IP packets because of the compound packet structure.
This was pass. For
these sites, mixing may not explained clearly enough, resulting in incorrect
implementations. It is suggested that the current padding
mechanism for RTCP packets (only) be deprecated. In its place,
a new RTCP packet necessary, in which case another type "PAD" could be defined that is always to
be ignored. That packet can take whatever length (in 32-bit
words) is required for padding, assuming there is no need to
pad to odd boundaries. The new mechanism would
of RTP-level relay called a translator may be backward
compatible because older implementations should ignore the
unknown PAD packet type.

o It is specified that sources should add random offsets to the
sequence number and timestamp fields to make known-plaintext
attacks used. Two translators
are installed, one on encryption more difficult, even if either side of the source itself
does not encrypt, because firewall, with the outside
one funneling all multicast packets may flow received through a
translator that does. However, secure
connection to the translator cannot depend
upon the source to do this. Should inside the firewall. The translator be allowed
inside the firewall sends them again as multicast packets to add its own random offsets a
multicast group restricted to these fields and the
corresponding fields in RTCP packets?

o The discussion of security issues site's internal network.

Mixers and translators may need to be expanded. In
particular, it has been recommended designed for a variety of purposes. An
example is a video mixer that scales the confidentiality
mechanisms defined images of individual people
in this document should follow the same
overall format as the IPSEC ESP work, unless there is some
compelling reason not to.

2 RTP Use Scenarios

The following sections describe some aspects separate video streams and composites them into one video stream
to simulate a group scene. Other examples of translation include the use
connection of RTP. The
examples were chosen to illustrate the basic operation a group of
applications using RTP, not hosts speaking only IP/UDP to limit what RTP may be used for. In
these examples, RTP is carried on top a group of IP and UDP, and follows
hosts that understand only ST-II, or the
conventions established by packet-by-packet encoding
translation of video streams from individual sources without
resynchronization or mixing. Details of the profile for audio operation of mixers and video specified
translators are given in Section 7.

2.4 Layered Encodings

Multimedia applications should be able to adjust the companion RFC 1890 (updated by Internet-Draft draft-ietf-avt-

Schulzrinne/Casner/Frederick/Jacobson [Page 7]

Internet Draft RTP December 5, 1997

profile-new ).

2.1 Simple Multicast Audio Conference

A working group transmission
rate to match the capacity of the IETF meets receiver or to discuss adapt to network
congestion. Many implementations place the latest protocol
draft, using responsibility of rate-
adaptivity at the IP source. This does not work well with multicast services
transmission because of the Internet for voice
communications. Through some allocation mechanism the working group
chair obtains a multicast group address and pair conflicting bandwidth requirements of ports. One port
heterogeneous receivers. The result is used for audio data, and often a least-common
denominator scenario, where the other is used for control (RTCP)
packets. This address and port information is distributed to smallest pipe in the
intended participants. If privacy is desired, network mesh
dictates the data quality 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 fidelity of these allocation and distribution mechanisms are beyond the scope of RTP.

The audio conferencing application used overall live multimedia
"broadcast".

Instead, responsibility for rate-adaptation can be placed at the
receivers by each conference
participant sends audio data in small chunks of, say, 20 ms duration.
Each chunk combining a layered encoding with a layered transmission
system. In the context of audio data is preceded by an RTP header; RTP header and
data are in turn contained in over IP multicast, the source can
stripe the progressive layers of a UDP packet. The hierarchically represented signal
across multiple RTP header indicates
what type of audio encoding (such as PCM, ADPCM or LPC) is contained
in sessions each packet so that senders carried on its own multicast group.
Receivers can change the encoding during a
conference, for example, to accommodate a new participant that is
connected through a low-bandwidth link or react then adapt to indications of network congestion.

The Internet, like other packet networks, occasionally loses and
reorders packets heterogeneity and delays them control their
reception bandwidth by variable amounts joining only the appropriate subset of time. To cope
with these impairments, the

Schulzrinne/Casner/Frederick/Jacobson [Page 7]

Internet Draft 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 August 7, 1998

multicast groups.

Details of
audio are contiguously played out the speaker every 20 ms. This
timing reconstruction is performed separately for each source use of RTP
packets in the conference. The sequence number can also be used by
the receiver to estimate how many packets with layered encodings are being lost.

Since members of the working group join given in
Sections 6.3.9, 8.3 and leave during the
conference, it is useful to know who is participating at any moment 10.

3 Definitions

RTP payload: The data transported by RTP in a packet, for example
audio samples or compressed video data. The payload format and how well they
interpretation are receiving beyond the audio data. For that purpose,
each instance scope of this document.

RTP packet: A data packet consisting of the audio application in the conference periodically
multicasts fixed RTP header, a reception report plus the name
possibly empty list of its user on the RTCP
(control) port. The reception report indicates how well the current
speaker is being received contributing sources (see below), and the
payload data. Some underlying protocols may be used to control adaptive
encodings. In addition require an
encapsulation of the RTP packet to be defined. Typically one
packet of the user name, other identifying
information underlying protocol contains a single RTP packet,
but several RTP packets may also be included subject to control bandwidth limits.
A site sends contained if permitted by the
encapsulation method (see Section 10).

RTCP BYE packet: A control packet (Section 6.6) when it leaves the
conference.

Schulzrinne/Casner/Frederick/Jacobson [Page 8]

Internet Draft consisting of a fixed header part
similar to that of RTP December 5, 1997

2.2 Audio and Video Conference

If both audio and video media data packets, followed by structured
elements that vary depending upon the RTCP packet type. The
formats are used defined in a conference, they are
transmitted as separate RTP sessions Section 6. Typically, multiple 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 sent together as a user participating compound RTCP packet in both
sessions should use a single
packet of the same distinguished (canonical) name underlying protocol; this is enabled by the length
field in the fixed header of each RTCP packets for both so 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." [4] The
transport selectors (TSEL) used by the sessions can be associated.

One motivation for this separation is OSI transport layer are
equivalent to allow some participants in ports. RTP depends upon the conference lower-layer protocol
to receive only one medium if they choose. Further
explanation is given in Section 5.2. Despite provide some mechanism such as ports to multiplex the separation,
synchronized playback of a source's audio RTP and video can be achieved
using timing information carried in the
RTCP packets for both
sessions.

2.3 Mixers of a session.

Transport address: The combination of a network address and Translators

So far, we have assumed port that all sites want
identifies a transport-level endpoint, for example an IP address
and a UDP port. Packets are transmitted from a source transport
address to receive a destination transport address.

RTP media data in type: An RTP media type is the same format. However, this may not always collection of payload types
which can be appropriate.
Consider the case where participants in one area are connected
through carried within a low-speed link single RTP session. The RTP
Profile assigns RTP media types to the majority RTP payload types.

RTP session: The association among a set 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
communicating with RTP. For each participant, the constant 20 ms spacing generated session is
defined by the sender, mixes these
reconstructed audio streams into a single stream, translates the
audio encoding to particular pair of destination transport addresses
(one network address plus a lower-bandwidth one port pair for RTP and forwards the lower-
bandwidth packet stream across RTCP). The

Schulzrinne/Casner/Frederick/Jacobson [Page 8]

Internet Draft RTP August 7, 1998

destination transport address pair may be common for all
participants, as in the low-speed link. These packets
might case of IP multicast, or may be
different for each, as in the case of individual unicast to network
addresses and port pairs. In a single recipient or multicast on multimedia session, each medium
is carried in a different
address to separate RTP session with its own RTCP packets.
The multiple recipients. RTP sessions are distinguished by different port
number pairs and/or different multicast addresses.

Synchronization source (SSRC): The source of a stream of RTP header includes packets,
identified by a means for
mixers to identify 32-bit numeric SSRC identifier carried in the sources that contributed to a mixed packet
RTP header so
that correct talker indication can as not to be provided at the receivers.

Some of the intended participants in dependent upon 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
application-level firewall that will not let any IP network address.
All packets pass. For
these sites, mixing may not be necessary, in which case another type
of RTP-level relay called from a translator may be used. Two translators
are installed, one on either side synchronization source form part of the firewall, with same
timing and sequence number space, so a receiver groups packets
by synchronization source for playback. Examples of
synchronization sources include the outside
one funneling all multicast sender of a stream of
packets received through derived from a secure
connection to the translator inside the firewall. The translator
inside the firewall sends them again signal source such as multicast packets to a
multicast group restricted to the site's internal network.

Schulzrinne/Casner/Frederick/Jacobson [Page 9]

Internet Draft microphone or a
camera, or an RTP December 5, 1997

Mixers and translators 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 designed 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 variety multimedia session; the binding of purposes. An
example the SSRC
identifiers is provided through RTCP (see Section 6.5.1). If a video mixer that scales the images of individual people
in separate video
participant generates multiple streams and composites them into in one RTP session, for
example from separate video stream
to simulate cameras, each must be identified as
a group scene. Other examples of translation include the
connection different SSRC.

Contributing source (CSRC): A source of a group stream of hosts speaking only IP/UDP RTP packets that
has contributed to the combined stream produced by an RTP mixer
(see below). The mixer inserts a group list of
hosts that understand only ST-II, or the packet-by-packet encoding
translation SSRC identifiers of video streams from individual
the sources without
resynchronization or mixing. Details that contributed to the generation of a particular
packet into the operation RTP header of mixers and
translators are given in Section 7.

2.4 Layered Encodings

Multimedia applications should be able to adjust that packet. This list is called
the transmission
rate CSRC list. An example application is audio conferencing
where a mixer indicates all the talkers whose speech was
combined to match produce the capacity of outgoing packet, allowing the receiver or to adapt
to network
congestion. Many implementations place indicate the responsibility of rate-
adaptivity at current talker, even though all the source. This does not work well with multicast
transmission because of audio
packets contain the conflicting bandwidth requirements same SSRC identifier (that of
heterogeneous receivers. The result is often a least-common
denominator scenario, where the smallest pipe in the network mesh
dictates the quality and fidelity of mixer).

End system: An application that generates the overall live multimedia
"broadcast".

Instead, responsibility for rate-adaptation can content to be placed at the
receivers by combining a layered encoding with a layered transmission
system. In sent in
RTP packets and/or consumes the context content of received RTP over IP multicast, the source packets.
An end system can
stripe the progressive layers of a hierarchically represented signal
across multiple act as one or more synchronization sources in
a particular RTP sessions each carried on its own multicast group.
Receivers can then adapt to network heterogeneity and control their
reception bandwidth by joining session, but typically only one.

Mixer: An intermediate system that receives RTP packets from one or
more sources, possibly changes the appropriate subset of the
multicast groups.

Details of data format, combines the use of RTP with layered encodings are given
packets in
Sections 6.3.9, 8.3 some manner and 10.

3 Definitions

RTP payload: The data transported by RTP in then forwards a packet, for example
audio samples or compressed video data. The payload format and
interpretation are beyond the scope of this document. new RTP packet: A data packet consisting of packet. Since
the fixed RTP header, a
possibly empty list of contributing timing among multiple input sources (see below), and the
payload data. Some underlying protocols may require an
encapsulation of the RTP packet to will not generally be defined. Typically one
packet of
synchronized, the underlying protocol contains a single RTP packet,
but several RTP packets may be contained if permitted by mixer will make timing adjustments among the
encapsulation method (see Section 10).

Schulzrinne/Casner/Frederick/Jacobson [Page 10] 9]

Internet Draft RTP December 5, 1997

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 August 7, 1998

streams and generate its own timing for the RTCP packet type. The
formats are defined in Section 6. Typically, multiple RTCP combined stream.
Thus, all data packets are sent together as originating from a compound RTCP packet in a single
packet of mixer will be
identified as having the underlying protocol; this is enabled 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 the length
field
participants in an RTP session, in particular the fixed header reception
reports, and estimates the current quality of each RTCP packet.

Port: service for
distribution monitoring, fault diagnosis and long-term
statistics. The "abstraction that transport protocols use monitor function is likely to distinguish
among multiple destinations within be built into the
application(s) participating in the session, but may also be a given host computer. TCP/IP
protocols identify ports using small positive integers." [3] The
transport selectors (TSEL) used by
separate application that does not otherwise participate and
does not send or receive the OSI transport layer RTP data packets. These are
equivalent called
third party monitors.

Non-RTP means: Protocols and mechanisms that may be needed in
addition 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.

Transport address: The combination of usable service. In particular, for
multimedia conferences, a network address conference control application may
distribute multicast addresses and port that
identifies a transport-level endpoint, keys for example an IP address
and a UDP port. Packets are transmitted from a source transport
address to a destination transport address.

RTP media type: An RTP media type is encryption,
negotiate the collection of payload types
which can be carried within a single RTP session. The RTP
Profile assigns RTP media types encryption algorithm to be used, and define
dynamic mappings between RTP payload types.

RTP session: The association among a set of participants
communicating with RTP. For each participant, type values and the session is
defined by payload
formats they represent for formats that do not have a particular pair of destination transport addresses
(one network address plus predefined
payload type value. For simple applications, electronic mail or
a port pair for RTP and RTCP). The
destination transport address pair conference database may also be common for all
participants, as in the case used. The specification of IP multicast, or may be
different for each, as in
such protocols and mechanisms is outside the case scope of individual unicast network
addresses this
document.

4 Byte Order, Alignment, and port pairs. In a multimedia session, each medium
is Time Format

All integer fields are 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): network byte order, that is, most
significant byte (octet) first. This byte order is commonly known as
big-endian. The source of a stream of RTP packets,
identified by a 32-bit transmission order is described in detail in [5].
Unless otherwise noted, numeric SSRC identifier carried constants are in the
RTP decimal (base 10).

All header so as not data is aligned 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 its natural length, i.e., 16-bit fields
are aligned on even offsets, 32-bit fields are aligned at offsets
divisible by synchronization source for playback. Examples of
synchronization sources include four, etc. Octets designated as padding have the sender of a stream value
zero.

Wallclock time (absolute date and time) is represented using the
timestamp format 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 Network Time Protocol (NTP), which is in
seconds relative to 0h UTC on 1 January 1900 [6]. The
SSRC identifier full resolution
NTP timestamp is a randomly chosen value meant to be globally 64-bit unsigned fixed-point number with the

Schulzrinne/Casner/Frederick/Jacobson [Page 11] 10]

Internet Draft RTP December 5, 1997

unique within a particular RTP session (see Section 8). A
participant need not use the same SSRC identifier for all the
RTP sessions August 7, 1998

integer part in a multimedia session; the binding of first 32 bits and the SSRC
identifiers is provided through RTCP (see Section 6.5.1). If a
participant generates multiple streams fractional part in one RTP session, for
example from separate video cameras, each must be identified as
a different SSRC.

Contributing source (CSRC): A source of the last
32 bits. In some fields where a stream of RTP packets more compact representation is
appropriate, only the middle 32 bits are used; that
has contributed to is, the combined stream produced by an RTP mixer
(see below). The mixer inserts a list low 16
bits of the SSRC identifiers of integer part and the sources that contributed to high 16 bits of the generation fractional part.
The high 16 bits of a particular
packet into the integer part must be determined
independently.

5 RTP Data Transfer Protocol

5.1 RTP Fixed Header Fields

The RTP header of that packet. This list is called 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 list. An example application identifiers is audio conferencing
where present only when inserted by a mixer indicates all the talkers whose speech was
combined to produce the outgoing packet, allowing the receiver
to indicate mixer.
The fields have the current talker, even though all following meaning:

version (V): 2 bits
This field identifies the audio
packets contain version of RTP. The version defined by
this specification is two (2). (The value 1 is used by the same SSRC identifier (that first
draft version of RTP and the mixer).

End system: An application that generates value 0 is used by the content to be sent protocol
initially implemented in
RTP packets and/or consumes the content of received RTP packets.
An end system can act as "vat" audio tool.)

padding (P): 1 bit
If the padding bit is set, the packet contains 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
additional padding octets at the timing among multiple input sources will end which are not generally be
synchronized, the mixer will make timing adjustments among part of the
streams and generate its own timing for
payload. The last octet of the combined stream.
Thus, all data packets originating from padding contains a mixer will count of how
many padding octets should be
identified as having the mixer as their synchronization source.

Translator: An intermediate system that forwards ignored, including itself.
Padding may be needed by some encryption algorithms with fixed
block sizes or for carrying several 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 a lower-layer
protocol data unit.

extension (X): 1 bit
If the extension bit is set, the fixed header is followed by
participants
exactly one header extension, with a format defined in an Section

Schulzrinne/Casner/Frederick/Jacobson [Page 11]

Internet Draft RTP session, in particular the reception
reports, and estimates August 7, 1998

5.3.1.

CSRC count (CC): 4 bits
The CSRC count contains the current quality number of service for
distribution monitoring, fault diagnosis and long-term
statistics. CSRC identifiers that
follow the fixed header.

marker (M): 1 bit
The monitor function is likely to be built into interpretation of the
application(s) participating marker is defined by a profile. It is
intended to allow significant events such as frame boundaries to
be marked in the session, but packet stream. A profile may also be a
separate application that does not otherwise participate and
does not send define additional
marker bits or receive the RTP data packets. These are called
third party monitors.

Schulzrinne/Casner/Frederick/Jacobson [Page 12]

Internet Draft RTP December 5, 1997

Non-RTP means: Protocols and mechanisms specify that may be needed there is no marker bit by changing
the number of bits 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 field (see Section 5.3).

payload type (PT): 7 bits
This field identifies the format of the RTP payload
formats they represent for formats that do not have and
determines its interpretation by the application. A profile
specifies a predefined default static mapping of payload type value. For simple applications, electronic mail or
a conference database codes to
payload formats. Additional payload type codes may also be used. The specification defined
dynamically through non-RTP means (see Section 3). An initial
set of
such protocols default mappings for audio and mechanisms video is outside specified in the scope of this
document.

4 Byte Order, Alignment,
companion RFC 1890 (updated by Internet-Draft draft-ietf-avt-
profile-new ), and Time Format

All integer fields are carried may be extended 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).

All header data is aligned to its natural length, i.e., 16-bit fields
are aligned on even offsets, 32-bit fields are aligned future editions of the
Assigned Numbers RFC [7]. An RTP sender emits a single RTP
payload type at offsets
divisible any given time; this field is not intended for
multiplexing separate media streams (see Section 5.2).

A receiver MUST ignore packets with payload types that it does not
understand.

sequence number: 16 bits
The sequence number increments by one for each RTP data packet
sent, and may be used by four, etc. Octets designated as padding have the receiver to detect packet loss and
to restore packet sequence. The initial value
zero.

Wallclock time (absolute time) is represented using the timestamp
format of the Network Time Protocol (NTP), which is in seconds
relative sequence
number SHOULD be random (unpredictable) to 0h UTC make known-plaintext
attacks on 1 January 1900 [5]. The full resolution NTP
timestamp is a 64-bit unsigned fixed-point number with the integer
part in encryption more difficult, even if the first 32 bits and source itself
does not encrypt according to the fractional part method in Section 9.1, because
the last 32
bits. In some fields where packets may flow through a more compact representation is
appropriate, only the middle translator that does. Techniques
for choosing unpredictable numbers are discussed in [8].

timestamp: 32 bits are used; that is,
The timestamp reflects the low 16
bits sampling instant of the integer part and the high 16 bits of first octet
in the fractional part. RTP data packet. The high 16 bits sampling instant must be derived
from a clock that increments monotonically and linearly in time
to allow synchronization and jitter calculations (see Section
6.4.1). The resolution of the integer part clock must be determined
independently.

5 RTP Data Transfer Protocol

5.1 RTP Fixed Header Fields sufficient for the
desired synchronization accuracy and for measuring packet
arrival jitter (one tick per video frame is typically not
sufficient). The RTP header has clock frequency is dependent on the following format: format of

Schulzrinne/Casner/Frederick/Jacobson [Page 13] 12]

Internet Draft RTP December 5, 1997

The first twelve octets are present in every RTP packet, while the
list of CSRC identifiers August 7, 1998

data carried as payload and is present only when inserted by a mixer.
The fields have the following meaning:

version (V): 2 bits
This field identifies specified statically in the version of RTP. The version defined by
this
profile or payload format specification is two (2). (The value 1 is used by that defines the first
draft version of format,
or may be specified dynamically for payload formats defined
through non-RTP means. If RTP and packets are generated
periodically, the value 0 nominal sampling instant as determined from
the sampling clock is used by to be used, not a reading of the protocol
initially implemented in the "vat" system
clock. As an example, for fixed-rate audio tool.)

padding (P): 1 bit
If the padding bit is set, the packet contains timestamp clock
would likely increment by one or more
additional padding octets at the end which are not part of for each sampling period. If an
audio application reads blocks covering 160 sampling periods
from the
payload. The last octet of input device, the padding contains a count of how
many padding octets should be ignored, including itself.
Padding may timestamp would be needed increased by some encryption algorithms with fixed
block sizes or 160
for carrying several RTP packets in a lower-layer
protocol data unit.

extension (X): 1 bit
If the extension bit is set, each such block, regardless of whether the fixed header block is followed by
exactly one header extension, with a format defined
transmitted 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 a packet or dropped as silent.

The interpretation initial value of the marker is defined by a profile. It timestamp is
intended to allow significant events such random, as frame boundaries for the sequence
number. Several consecutive RTP packets may have equal timestamps if
they are (logically) generated at once, e.g., belong to
be marked in the packet stream. A profile same
video frame. Consecutive RTP packets may define additional
marker bits or specify contain timestamps that there are
not monotonic if the data is no marker bit by changing not transmitted in the number of bits order it was
sampled, as in the payload type field (see Section 5.3).

Schulzrinne/Casner/Frederick/Jacobson [Page 14]

Internet Draft RTP December 5, 1997

payload type (PT): 7 case of MPEG interpolated video frames. (The
sequence numbers of the packets as transmitted will still be
monotonic.)

SSRC: 32 bits
This
The SSRC field identifies the format of synchronization source. This
identifier is chosen randomly, with the intent that no two
synchronization sources within the same RTP payload and
determines its interpretation by session will have
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). same SSRC identifier. An initial
set of default mappings example algorithm for audio and video generating a
random identifier is specified presented in Appendix A.6. Although the
companion RFC 1890 (updated by Internet-Draft draft-ietf-avt-
profile-new ), and may be extended in future editions
probability of multiple sources choosing the
Assigned Numbers RFC [6]. An RTP sender emits a single RTP
payload type at any given time; this field same identifier is not intended for
multiplexing separate media streams (see Section 5.2).

A receiver MUST ignore packets with payload types that it does not
understand.

sequence number: 16 bits
The sequence number increments by one for each
low, all RTP data packet
sent, and may implementations must be used by the receiver prepared 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
resolve collisions. Section 8 describes the packets may flow through probability of
collision along with a translator that
does. Techniques mechanism for choosing unpredictable numbers are
discussed in [7].

timestamp: 32 bits
The timestamp reflects resolving collisions and
detecting RTP-level forwarding loops based on the sampling instant uniqueness of
the first octet
in the RTP data packet. The sampling instant SSRC identifier. If a source changes its source transport
address, it must be derived
from also choose a clock that increments monotonically and linearly in time new SSRC identifier to allow synchronization and jitter calculations avoid
being interpreted as a looped source (see Section
6.4.1). 8.2).

CSRC list: 0 to 15 items, 32 bits each
The resolution of CSRC list identifies the clock must be sufficient contributing sources for the
desired synchronization accuracy and for measuring packet
arrival jitter (one tick per video frame is typically not
sufficient).
payload contained in this packet. The clock frequency is dependent on the format number of
data carried as payload and identifiers is specified statically in the
profile or payload format specification that defines
given by the format,
or CC field. If there are more than 15 contributing
sources, only 15 may be specified dynamically for payload formats defined
through non-RTP means. If RTP packets identified. CSRC identifiers are generated
periodically, the nominal sampling instant as determined from
inserted by mixers, using the sampling clock is to be used, not a reading SSRC identifiers of the system
clock. As an contributing
sources. For 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, packets the timestamp would be increased by 160
for each such block, regardless SSRC identifiers of whether the block is
transmitted in a packet or dropped as silent.
all sources that were mixed together to create a packet are
listed, allowing correct talker indication at the receiver.

5.2 Multiplexing RTP Sessions

Schulzrinne/Casner/Frederick/Jacobson [Page 15] 13]

Internet Draft RTP December 5, 1997

The initial value August 7, 1998

For efficient protocol processing, the number of multiplexing points
should be minimized, as described in the timestamp integrated layer processing
design principle [1]. In RTP, multiplexing is random, as for provided by the sequence
number. Several consecutive
destination transport address (network address and port number) which
define an RTP packets may have equal timestamps if
they are (logically) generated at once, e.g., belong to the same session. For example, in a teleconference composed of
audio and video frame. Consecutive media encoded separately, each medium should be
carried in a separate RTP packets may contain timestamps that are
not monotonic if the data session with its own destination transport
address. It is not transmitted in the order it was
sampled, as in intended that the case of MPEG interpolated audio and video frames. (The
sequence numbers of the packets as transmitted will still streams be
monotonic.)

SSRC: 32 bits
The SSRC field identifies
carried in a single RTP session and demultiplexed based on the synchronization source. This
identifier is chosen randomly,
payload type or SSRC fields. Interleaving packets with different RTP
media types but using the intent that no same SSRC would introduce several problems:

1. If, say, two
synchronization sources within audio streams shared the same RTP session will have and
the same SSRC identifier. An example algorithm for generating value, and one were to change encodings and
thus acquire a
random identifier is presented in Appendix A.6. Although the
probability of multiple sources choosing the same identifier is
low, all different RTP implementations must payload type, there would 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
no general way of
the SSRC identifier. If a source changes its source transport
address, it must also choose a new identifying which stream had changed
encodings.

2. An SSRC identifier is defined to avoid
being interpreted as identify a looped source (see Section 8.2).

CSRC list: 0 to 15 items, 32 bits each
The CSRC list identifies the contributing sources for 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 contained in this packet. type suffered packet loss.

3. The RTCP sender and receiver reports (see Section 6.4) can
only describe one timing and sequence number of identifiers is
given by the CC space per SSRC
and do not carry a payload type field. If there are more than 15 contributing
sources, only 15 may

4. An RTP mixer would not be identified. CSRC identifiers are
inserted by mixers, using able to combine interleaved
streams of incompatible media into one stream.

5. Carrying multiple media in one RTP session precludes: the SSRC identifiers
use of contributing
sources. For example, different network paths or network resource
allocations if appropriate; reception of a subset of the
media if desired, for example just audio packets if video would
exceed 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 available bandwidth; and port number) which
define an receiver
implementations that use separate processes for the
different media, whereas using separate RTP session. For example, in sessions
permits either single- or multiple-process implementations.

Using a teleconference composed of
audio and video media encoded separately, different SSRC for each medium should be
carried but sending them in a separate the same
RTP session with its own destination transport
address. It is would avoid the first three problems but not intended that the audio and video streams be
carried in a single RTP session and demultiplexed based on last
two.

5.3 Profile-Specific Modifications to the
payload type or SSRC fields. Interleaving packets with different RTP
media types but using Header

The existing RTP data packet header is believed to be complete for
the same SSRC would introduce several problems: set of functions required in common across all the application

Schulzrinne/Casner/Frederick/Jacobson [Page 16] 14]

Internet Draft RTP December 5, 1997

1. If, say, two audio streams shared the same August 7, 1998

classes that RTP session and might support. However, in keeping with the same SSRC value, ALF
design principle, the header may be tailored through modifications or
additions defined in a profile specification while still allowing
profile-independent monitoring and one were recording tools to change encodings function.

o The marker bit and
thus acquire a different RTP payload type, there would be
no general way of identifying which stream had changed
encodings.

2. An SSRC is defined type field carry profile-specific
information, but they are allocated in the fixed header since
many applications are expected to identify a single timing need them and sequence
number space. Interleaving multiple payload types would
require 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 timing spaces if requirements, for example with a more or fewer marker
bits. If there are any marker bits, one should be located in
the media clock rates
differ and would require different sequence number spaces most significant bit of the octet since profile-independent
monitors may be able to tell which payload type suffered observe a correlation between packet loss.

3. The RTCP sender and receiver reports (see Section 6.4) can
only describe one timing and sequence number space per SSRC
loss patterns and do not carry the marker bit.

o Additional information that is required for a particular
payload type field.

4. An RTP mixer would not format, such as a video encoding, should be able to combine interleaved
streams carried in
the payload section of incompatible media into one stream.

5. Carrying multiple media the packet. This might be in one RTP session precludes: a header
that is always present at the
use start of different network paths the payload section, or network resource
allocations if appropriate; reception of
might be indicated by a subset reserved value in the data pattern.

o If a particular class of applications needs additional
functionality independent of payload format, the
media if desired, for example just audio if video would
exceed profile under
which those applications operate should define additional fixed
fields to follow immediately after the available bandwidth; SSRC field of the
existing fixed header. Those applications will be able to
quickly and receiver
implementations that use separate processes for directly access the
different media, whereas using separate RTP sessions
permits either single- additional fields while
profile-independent monitors or multiple-process implementations.

Using a different SSRC for each medium but sending them in recorders can still process the same
RTP session would avoid packets by interpreting only the first three problems but not the last
two.

5.3 Profile-Specific Modifications to the RTP Header

The existing RTP data packet header twelve octets.

If it turns out that additional functionality is believed to be complete for
the set of functions required needed in common
across all the application
classes that profiles, then a new version of RTP might support. However, in keeping with the ALF
design principle, the header may should be tailored through modifications or
additions defined in to
make a profile specification while still allowing
profile-independent monitoring and recording tools permanent change 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 header.

5.3.1 RTP Header Extension

An extension mechanism is provided to need them and might otherwise
have allow individual
implementations to add another 32-bit word just experiment with new payload-format-independent
functions that require additional information to hold them. The octet
containing these fields be carried in the
RTP data packet header. This mechanism is designed so that the header
extension may be redefined ignored by a profile to suit
different requirements, other interoperating implementations that
have not been extended.

Note that this header extension is intended only for example with a more or fewer marker
bits. If there are any marker bits, one should limited use.
Most potential uses of this mechanism would be located better done another
way, using the methods described in the previous section. For
example, a profile-specific extension to the fixed header is less

Schulzrinne/Casner/Frederick/Jacobson [Page 17] 15]

Internet Draft RTP December 5, 1997

the most significant bit of the octet since profile-independent
monitors may be able August 7, 1998

expensive to observe process because it is not conditional nor in a correlation between packet
loss patterns and the marker bit.

o variable
location. Additional information that is required for a particular payload format, such as a video encoding,
format should not use this header extension, but should be carried in
the payload section of the packet. This might be

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
that
extension is always present at appended to the start of RTP header, following the payload section, or
might be indicated by CSRC list if
present. The header extension contains a reserved value in 16-bit length field that
counts the data pattern.

o If a particular class of applications needs additional
functionality independent number of payload format, 32-bit words in 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 extension, excluding the first twelve octets.

If it turns out that additional functionality
four-octet extension header (therefore zero is needed in common
across all profiles, then a new version of RTP should be defined to
make valid length). Only
a permanent change single extension may be appended to the fixed header.

5.3.1 RTP Header Extension

An extension mechanism is provided to data header. To allow individual
multiple interoperating implementations to each experiment
independently with new payload-format-independent
functions that require additional information different header extensions, or to be carried in allow a
particular implementation to experiment with more than one type of
header extension, the
RTP data packet header. This mechanism is designed so that first 16 bits of the header extension may are left
open for distinguishing identifiers or parameters. The format of
these 16 bits is to be ignored defined by other interoperating the profile specification under
which the implementations that
have are operating. This RTP specification does
not been extended.

Note that this define any header extension extensions itself.

6 RTP Control Protocol -- RTCP

The RTP control protocol (RTCP) is intended only for limited use.
Most potential uses based on the periodic transmission
of this mechanism would be better done another
way, control packets to all participants in the session, using the methods described in same
distribution mechanism as the previous section. For
example, a profile-specific extension to data packets. The underlying protocol
must provide multiplexing of the fixed header is less
expensive data and control packets, for
example using separate port numbers with UDP. RTCP performs four
functions:

1. The primary function is to process because it provide feedback on the quality
of the data distribution. This is not conditional nor in an integral part of the
RTP's role as a variable
location. Additional information required transport protocol and is related to the
flow and congestion control functions of other transport
protocols. The feedback may be directly useful for a particular payload
format should not use this header extension, control
of adaptive encodings [9,10], but should be carried in experiments with IP
multicasting have shown that it is also critical to get
feedback from the payload section of receivers to diagnose faults in the packet.
distribution. Sending reception feedback reports to all

Schulzrinne/Casner/Frederick/Jacobson [Page 18] 16]

Internet Draft RTP December 5, 1997

If the X bit in the RTP header August 7, 1998

participants allows one who is one, observing problems to
evaluate whether those problems are local or global. With a variable-length header
extension
distribution mechanism like IP multicast, it is appended to the RTP header, following the CSRC list if
present. The header extension contains also
possible for an entity such as a 16-bit length field that
counts the number of 32-bit words network service provider
who is not otherwise involved in the extension, excluding session to receive the
four-octet extension header (therefore zero is a valid length). Only
feedback information and act as a single extension may be appended third-party monitor to
diagnose network problems. This feedback function is
performed by the RTCP sender and receiver reports,
described below in Section 6.4.

2. RTCP carries a persistent transport-level identifier for an
RTP data header. To allow
multiple interoperating implementations to each experiment
independently with different header extensions, source called the canonical name or to allow CNAME, Section
6.5.1. Since the SSRC identifier may change if a
particular implementation conflict
is discovered or a program is restarted, receivers require
the CNAME to experiment with more than one type keep track of
header extension, each participant. Receivers may
also require the first 16 bits CNAME to associate multiple data streams
from a given participant in a set of the header extension are left
open related RTP sessions,
for distinguishing identifiers or parameters. The format of
these 16 bits is example to be defined by the profile specification under
which synchronize audio and video. Inter-media
synchronization also requires the implementations are operating. This RTP specification does
not define any header extensions itself.

6 NTP and RTP Control Protocol -- timestamps
included in RTCP packets by data senders.

3. The RTP control protocol (RTCP) is based on first two functions require that all participants send
RTCP packets, therefore the periodic transmission 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 participants in the session, using the same
distribution mechanism as others, each can independently observe
the data packets. The underlying protocol
must provide multiplexing number of participants. This number is used to
calculate the data and rate at which the packets are sent, as
explained in Section 6.2.

4. A fourth, optional function is to convey minimal session
control packets, information, for example using separate port numbers with UDP. RTCP performs four
functions:

1. The primary function is participant identification
to provide feedback on the quality
of be displayed in the data distribution. user interface. This is an integral part of the
RTP's role most likely
to be useful in "loosely controlled" sessions where
participants enter and leave without membership control or
parameter negotiation. RTCP serves as a transport protocol and convenient channel
to reach all the participants, but it is related not necessarily
expected to support all the
flow and congestion control functions communication
requirements of other transport
protocols. The feedback may be directly useful for an application. A higher-level session
control protocol, which is beyond the scope of adaptive encodings [8,9], this
document, may be needed.

Functions 1-3 SHOULD be used in all environments, but experiments with particularly in
the IP
multicasting have shown multicast environment. RTP application designers SHOULD avoid
mechanisms that it is also critical to get
feedback from the receivers to diagnose faults can only work in the
distribution. Sending reception feedback reports to all
participants allows one who is observing problems unicast mode and will not scale to
evaluate whether those problems are local or global. With a
distribution mechanism like IP multicast, it is also
possible
larger numbers. Transmission of RTCP MAY be controlled separately for an entity
senders and receivers for cases such as a network service provider
who unidirectional links where
feedback from receivers is not otherwise involved in the session to receive the possible.

Schulzrinne/Casner/Frederick/Jacobson [Page 19] 17]

Internet Draft RTP December 5, 1997

feedback information and act as a third-party monitor to
diagnose network problems. August 7, 1998

6.1 RTCP Packet Format

This feedback function is
performed by the specification defines several RTCP sender packet types to carry a
variety of control information:

SR: Sender report, for transmission and receiver reports,
described below in Section 6.4.

2. 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 carries packet begins with a persistent transport-level identifier for an fixed part similar to that of RTP source called the canonical name or CNAME, Section
6.5.1. Since the SSRC identifier data
packets, followed by structured elements that may change if be of variable
length according to the packet type but always end on a conflict
is discovered or 32-bit
boundary. The alignment requirement and a program is restarted, receivers require length field in the CNAME to keep track fixed
part of each participant. Receivers packet are included to make RTCP packets "stackable".
Multiple RTCP packets may
also require the CNAME be concatenated without any intervening
separators to associate multiple data streams
from form a given participant compound RTCP packet that is sent in a set single
packet of related RTP sessions, the lower layer protocol, for example to synchronize audio and video.

3. The first two functions require that all participants send UDP. There is no
explicit count of individual RTCP packets, therefore the rate must be controlled packets in
order for RTP to scale up to a large number of
participants. By having each participant send its control
packets the compound packet
since the lower layer protocols are expected to all provide an overall
length to determine the others, each can end of the compound packet.

Each individual RTCP packet in the compound packet may be processed
independently observe with no requirements upon the number order or combination of participants. This number is used
packets. However, in order to
calculate perform the rate at which functions of the packets protocol,
the following constraints are sent, imposed:

o Reception statistics (in SR or RR) should be sent as
explained in Section 6.2.

4. A fourth, optional function is to convey minimal session
control information, for example participant identification often as
bandwidth constraints will allow to be displayed in maximize 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. resolution of
the statistics, therefore each periodically transmitted
compound RTCP serves as packet should include a convenient channel report packet.

o New receivers need to reach all receive the participants, but it is not necessarily
expected CNAME for a source as soon
as possible to support all identify the control communication
requirements of an application. A higher-level session
control protocol, which is beyond source and to begin associating
media for purposes such as lip-sync, so each compound RTCP
packet should also include the scope SDES CNAME.

o The number of this
document, packet types that may appear first in the
compound packet should be needed.

Functions 1-3 are mandatory when RTP is used limited to increase the number of
constant bits 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 first word and will not scale to larger numbers.

6.1 RTCP Packet Format

This specification defines several RTCP packet types to carry a
variety the probability of control information:

SR: Sender report, for transmission and reception statistics from
participants that are active senders
successfully validating RTCP packets against misaddressed RTP

Schulzrinne/Casner/Frederick/Jacobson [Page 20] 18]

Internet Draft RTP December 5, 1997

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 August 7, 1998

data packets or other unrelated packets.

Thus, all RTCP packet begins with packets MUST be sent in a fixed part similar to that compound packet of RTP data at least
two individual packets, followed by structured elements that may be of variable
length according to with the packet type but always end on a 32-bit
boundary. The alignment requirement following format recommended:

Encryption prefix: If and a length field in only if the fixed
part of each compound packet are included is to make RTCP packets "stackable".
Multiple RTCP packets may be concatenated without any intervening
separators
encrypted according to form the method in Section 9.1, it MUST be
prefixed by a random 32-bit quantity redrawn for every compound RTCP
packet that transmitted. If padding is sent in a single required for the encryption,
it MUST be added to the last packet of the lower layer protocol, for example UDP. There is no
explicit count of individual compound packet.

SR or RR: The first RTCP packets packet 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
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.

Schulzrinne/Casner/Frederick/Jacobson [Page 21]

Internet Draft RTP December 5, 1997

SR or RR: The first RTCP packet in the compound packet must 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.3.9).

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).

6.2 RTCP Transmission Interval

Schulzrinne/Casner/Frederick/Jacobson [Page 19]

Internet Draft RTP is designed to allow an August 7, 1998

if encrypted: random 32-bit integer
|
|[------- packet -------][----------- packet -----------][-packet-]
|
| receiver chunk chunk
V reports 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

6.2 RTCP Transmission Interval

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.

Schulzrinne/Casner/Frederick/Jacobson [Page 22]

Internet Draft RTP December 5, 1997

#: SSRC/CSRC

Figure 1: Example of an RTCP compound packet
Therefore, the rate must be scaled down. down by dynamically calculating
the interval between RTCP packet transmissions.

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. If there is no reservation, there may be
other constraints, depending on the environment, that establish the
"reasonable" maximum for the session to use, and that would be the
session bandwidth. 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. Often, the
session bandwidth is the sum of the nominal bandwidths of the senders
expected to be concurrently active. For teleconference audio, this
number would typically be one sender's bandwidth. For layered

Schulzrinne/Casner/Frederick/Jacobson [Page 20]

Internet Draft RTP August 7, 1998

encodings, each layer is a separate RTP session with its own session
bandwidth parameter.

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.

Bandwidth calculations for control and data traffic include lower-
layer transport and network protocols (e.g., UDP and IP) since that

Schulzrinne/Casner/Frederick/Jacobson [Page 23]

Internet Draft RTP December 5, 1997
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 RECOMMENDED that the
fraction of the session bandwidth allocated to RTCP be fixed at 5%. While the
value
It is also RECOMMENDED that 1/4 of this and other constants in the interval calculation is not
critical, all RTCP bandwidth be dedicated to
participants that are sending data so that in sessions with a large
number of receivers but a small number of senders, newly joining
participants will more quickly receive the session must CNAME for the sending
sites. When the proportion of senders is greater than 1/4 of the
participants, the senders get their proportion of the full RTCP
bandwidth. While the values of these and other constants in the
interval calculation are 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

A profile MAY specify that the allowed control traffic bandwidth
among may be a
separate parameter of the participants. This session rather than a strict percentage of
the session bandwidth. Using a separate parameter allows an application rate-
adaptive applications to provide fast
response for small sessions where, for example, identification of all
participants set an RTCP bandwidth consistent with a
"typical" data bandwidth that is important, yet automatically adapt to large sessions.
The algorithm incorporates lower than the following characteristics:

o Senders are collectively allocated at least 1/4 of maximum bandwidth
specified by the session bandwidth parameter.

The profile MAY further specify that the control traffic bandwidth so
may be divided into two separate session parameters for those
participants which are active data senders and those which are not.
Following the recommendation that in sessions with a large number of
receivers but a small number 1/4 of the RTCP bandwidth be

Schulzrinne/Casner/Frederick/Jacobson [Page 21]

Internet Draft RTP August 7, 1998

dedicated to data senders, newly joining
participants will more quickly receive the CNAME RECOMMENDED default values for these
two parameters would be 1.25% and 3.75%, respectively. When the
sending sites.

o The calculated interval between RTCP packets
proportion of senders is required to be greater than a minimum of 5 seconds to avoid having bursts 1/4 of the participants, the
senders get their proportion of the sum of these parameters. Using
two parameters allows RTCP reception reports to be turned off
entirely for a particular session by setting the RTCP bandwidth for
non-data-senders to zero while keeping the RTCP bandwidth for data
senders non-zero so that sender reports can still be sent for inter-
media synchronization. This may be appropriate for systems operating
on unidirectional links or for sessions that don't require feedback
on the quality of reception.

The calculated interval between transmissions of compound RTCP
packets SHOULD also have a lower bound to avoid having bursts of
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 calculated It also keeps the report interval between RTCP packets scales linearly
with from becoming too small
during transient outages like a network partition such that
adaptation is delayed when the number of members in partition heals. At application
startup, a delay SHOULD be imposed before the group. It first compound RTCP
packet is this linear
factor which allows sent to allow time for a constant amount of control traffic
when summed across all members.

o The interval between RTCP packets is varied randomly over to be received from
other participants so the
range [0.5,1.5] times report interval will converge to the calculated
correct value more quickly. This delay MAY be set to half the
minimum interval to avoid
unintended synchronization of all participants [10]. allow quicker notification that the new
participant is present. The first
RTCP packet sent after joining RECOMMENDED value for a session fixed minimum
interval is also delayed by a
random variation of half 5 seconds.

An implementation MAY scale the minimum RTCP interval in case to a smaller
value inversely proportional to the

Schulzrinne/Casner/Frederick/Jacobson [Page 24]

Internet Draft RTP December 5, 1997

application is started at multiple sites simultaneously, for
example as initiated by a session announcement. bandwidth parameter with
the following limitations:

o A dynamic estimate of For multicast sessions, only active data senders MAY use the average compound RTCP packet size is
calculated, including all those received and sent, to
automatically adapt
reduced minimum value to changes in calculate the amount interval for
transmission of control
information carried. compound RTCP packets.

o Since the calculated interval is dependent on For unicast sessions, the number of
observed group members, there may reduced value MAY be an undesirable startup
effects when a new user joins an existing session, or many
users simultaneously join a new session. These new users will
initially have incorrect estimates of the group membership, used by
participants that are not active data senders as well, and
thus their the
delay before sending the initial compound RTCP transmission interval will packet may be too low. This
problem can
zero.

o For all sessions, the fixed minimum SHOULD be significant if many users join used when
calculating the session
simultaneously. To deal with this, an algorithm called "timer
reconsideration" is employed. This algorithm implements a
simple back-off mechanism participant timeout interval (see Section 6.3.5
so that implementations which causes users do not to hold back RTCP
packet transmission if use the group sizes reduced value
for transmitting RTCP packets are increasing.

o When users leave a session, either with a BYE or not timed out by timeout,
the group membership decreases, and thus other
participants prematurely.

o The RECOMMENDED value for the calculated
interval should decrease. A "reverse reconsideration" algorithm reduced minimum in seconds is used to allow members to more quickly reduce their intervals
360 divided by the session bandwidth in response to group membership decreases.

o BYE packets are given different treatment kilobits/second. This

Schulzrinne/Casner/Frederick/Jacobson [Page 22]

Internet Draft RTP August 7, 1998

minimum is smaller than normal RTCP
packets. When a user leaves a group, 5 seconds for bandwidths greater than
72 kb/s.

The algorithm described in Section 6.3 and wishes Appendix A.7 was designed
to send a BYE
packet, it may do so before its next scheduled meet the goals outlined above. It calculates the interval between
sending compound RTCP packet.
However, transmission of BYE's follows a back-off algorithm
which avoids floods of BYE packets should a large number of
members simultaneously leave to divide the session. allowed control traffic
bandwidth among the participants. This algorithm may be used allows an application to
provide fast response for small sessions in which where, for example,
identification of all participants are
allowed is important, yet automatically
adapt to send. In that case, large sessions. The algorithm incorporates the session bandwidth parameter is following
characteristics:

o The calculated interval between RTCP packets scales linearly
with the
product number of members in the individual sender's bandwidth group. It is this linear
factor which allows for a constant amount of control traffic
when summed across all members.

o The interval between RTCP packets is varied randomly over the
range [0.5,1.5] times the number calculated interval to avoid
unintended synchronization of
participants, and the all participants [11]. The first
RTCP bandwidth packet sent after joining a session is 5% of that.

Details also delayed by a
random variation of half the algorithm's operation are given in the sections that
follow. Appendix A.7 gives an example implementation.

6.3 minimum RTCP Packet Send and Receive Rules

The rules for how to send, and what to do when receiving an RTCP
packet are outlined here. To execute these rules, a session
participant must maintain several pieces interval.

o A dynamic estimate of state:

tp: the last time an average compound RTCP packet was transmitted;

Schulzrinne/Casner/Frederick/Jacobson [Page 25]

Internet Draft RTP December 5, 1997

tc: the current time;

tn: the next scheduled transmission time of an RTCP packet;

pmembers: size is
calculated, including all those received and sent, to
automatically adapt to changes in the estimated number amount of session members at time tp

members: control
information carried.

o Since the most current estimate for calculated interval is dependent on the number of session members;

senders: the most current estimate for the number
observed group members, there may be undesirable startup
effects when a new user joins an existing session, or many
users simultaneously join a new session. These new users will
initially have incorrect estimates of senders in the
session;

rtcp_bw: The target group membership, and
thus their RTCP bandwidth, i.e., the total bandwidth that transmission interval will be used for RTCP packets by all members of this session, in
octets per second. too short. This should
problem can be 5% of the "session bandwidth"
parameter supplied to the application at startup.

we_sent: Flag that is true significant if many users join the application has sent data since the
2nd previous RTCP report was transmitted.

avg_rtcp_size: The average compound session
simultaneously. To deal with this, an algorithm called "timer
reconsideration" is employed. This algorithm implements a
simple back-off mechanism which causes users to hold back RTCP
packet size, in octets, over
all RTCP packets sent and received by this user.

initial: Flag that is true transmission if the application has not yet sent an
RTCP packet.

Many of these rules make use of group sizes are increasing.

o When users leave a session, either with a BYE or by timeout,
the "calculated interval" between
packet transmissions. This group membership decreases, and thus the calculated
interval should decrease. A "reverse reconsideration" algorithm
is described used to allow members to more quickly reduce their intervals
in the following
section.

6.3.1 Computing the response to group membership decreases.

o BYE packets are given different treatment than other RTCP
packets. When a user leaves a group, and wishes to send a BYE

Schulzrinne/Casner/Frederick/Jacobson [Page 23]

Internet Draft RTP August 7, 1998

packet, it may do so before its next scheduled RTCP packet.
However, transmission interval

To maintain scalability, the average interval between packets from of BYE's follows a
session participant back-off algorithm
which avoids floods of BYE packets should scale with a large number of
members simultaneously leave the group size. session.

This interval
is called algorithm may be used for sessions in which all participants are
allowed to send. In that case, the calculated interval. It session bandwidth parameter is obtained by combining a
number the
product of the pieces individual sender's bandwidth times the number of state described above. The calculated
interval T
participants, and the RTCP bandwidth is then determined as follows:

1. If there 5% of that.

Details of the algorithm's operation are any senders (senders > 0) given in the session, but sections that
follow. Appendix A.7 gives an example implementation.

6.2.1 Maintaining the number of senders is less than 25% session members

Calculation of the membership
(members), the RTCP packet interval depends on whether the user is a
sender or not (based on the value upon an estimate of we_sent). If
the user
is a sender (we_sent true), number of sites participating in the constant C is set session. New sites are added
to the
average rtcp packet size (avg_rtcp_size) divided by 25% of
the rtcp bandwidth (rtcp_bw), count when they are heard, and an entry for each SHOULD be
created in a table indexed by the constant n is set SSRC or CSRC identifier (see
Section 8.2) to
the number keep track of senders. If we_sent is them. New entries MAY be considered not true,
valid until multiple packets carrying the constant
C is set to new SSRC have been received
(see Appendix A.1). Entries MAY be deleted from the average rtcp table when an
RTCP BYE packet size divided by 75% of with the rtcp bandwidth. The constant n corresponding SSRC identifier is set to received,
except that some straggler data packets might arrive after the number of
receivers (members - senders).

Schulzrinne/Casner/Frederick/Jacobson [Page 26]

Internet Draft RTP December 5, 1997

2. If BYE
and cause the user has entry to be recreated. Instead, the entry should be
marked as having received a BYE and then deleted after an appropriate
delay.

A participant may mark another site inactive, or delete it if not yet sent an
valid, if no RTP or RTCP packet (the variable
initial has been received for a small number
of RTCP report intervals (5 is false), suggested). This provides some
robustness against packet loss. All sites must calculate roughly the constant Tmin is set
same value for the RTCP report interval in order for this timeout to 5 seconds,
else
work properly.

Once a site has been validated, then if it is set to 2.5 seconds.

3. The deterministic calculated interval Td is set to
max(Tmin, n*C).

4. The calculated interval T is set to a number uniformly
distributed between half later marked inactive
the state for that site should still be retained and three half the deterministic
calculated interval.

This procedure results site should
continue to be counted in an interval which is random, but which, on
average, gives 25% of the rtcp total number of sites sharing RTCP
bandwidth for a period long enough to senders, and 75% to
receivers.

6.3.2 Initialization

Upon joining the session, the user initializes tp to 0, tc to 0,
senders to 0, initial to 1, pmembers to 1, members to 1, we_sent to
false, rtcp_bw span typical network
partitions. This is to 5% of avoid excessive traffic, when the session bandwidth, initial to true, and
avg_pkt_sz partition
heals, due to the size of the very first packet constructed by the
application. The calculated an RTCP report interval T is then computed, and the
first packet is scheduled for time tn = T. This means that a
transmission timer is set which expires at time T. too small. A timeout of
30 minutes is suggested. Note that the user
MAY use any desired approach for implementing this timer.

The user adds their own SSRC is still larger than 5 times
the largest value to which the member table.

6.3.3 Receiving an RTP or non-BYE RTCP packet

When an RTP or RTCP packet report interval is received from expected to
usefully scale, about 2-5 minutes.

For sessions with a user whose SSRC is not
in the member table, the SSRC is added very large number of participants, it may be
impractical to maintain a table to store the table, SSRC identifier and the value
state information for members is incremented by 1.

When an RTP packet is received from a user whose SSRC is not in the
sender table, the SSRC is added to the table, and the value for
senders is incremented by 1.

For large scale applications, such as a broadcast session, the
approach of storing all the received SSRC identifiers in a table does
not scale well. For huge groups, the amound of memory required to
store all the SSRC identifiers and related per-source state may
become impractical.

To reduce this storage burden, an application them. An implementation MAY instead store only
a sampling of the received use SSRC identifiers using the algorithm

Schulzrinne/Casner/Frederick/Jacobson [Page 24]

Internet Draft RTP August 7, 1998

sampling, as described here, or to reduce the storage requirements. An
implementation MAY use any other algorithm with similar behavior. The performance.
A key requirement is that any algorithm operates by attempting to maintain the number of entries

Schulzrinne/Casner/Frederick/Jacobson [Page 27]

Internet Draft RTP December 5, 1997

stored below some threshold, B. This threshold considered SHOULD NOT be less
than 100 in order to achieve sufficient statistical accuracy in
substantially underestimate the
sampling. group size, although it MAY
overestimate.

The idea is to filter which SSRC identifiers are stored based on sampling algorithm employs a
mask. A participant mask with the m least significant
bits set to one and uses its the participant's own SSRC identifier as the a
(random) key, and starts
with key. If a mask of 0 bits (so all other SSRC identifiers newly received will
match). Matching SSRC identifiers are placed into matches the table. When key when both are
ANDed with the
table reaches full capacity (B), mask, the mask new SSRC identifier is extended by 1 bit.
(Shifting 1 bits into added to the least significant bit table,
otherwise it is recommended.)
Now, all of ignored. An exception is that the SSRC values identifiers of
data senders must be maintained in the table which no longer equal the
key even when their SSRC
does not match under the masking operation are discarded. On average, this
reduces because the size potentially
small number of senders must be accurate for the RTCP interval
calculation. Initially, the mask starts with m=0, so that every SSRC
identifier is accepted and placed into the table. When the number of
table entries reaches some threshold, B, m is increased by 1/2. As new 1 bit, and
all the SSRC identifiers are
received, they are only added to in the table if they which no longer match the key under the masking operation. Again, when
mask are discarded. This will reduce the table size increases by roughly half.
As the group size continues to
B, increase, the user MAY further
increase the mask is extended size by another bit, and an additional bit when the nonmatching entries
are discarded. table size once
again approaches the threshold. An implementation MUST maintain a
table that can accomodate at least B=100 users, for reasonable
statistical accuracy.

The mask may not be extended beyond algorithm also maintains a set of 32 bits, in which
case only the participants own bins, numbered 0 through 31.
When a new participant shows up whose SSRC would match.

If matches the key under the
current mask (with m bits), the SSRC identifier is placed in bin

in bin m that still match under the number m+1 bit mask are moved from bin m
to bin m+1, otherwise they are discarded as mentioned previously. The
SSRC identifiers of 1 bits data senders are always kept and are always
placed in the mask, and n 0th bin. When a sender stops sending, its SSRC is moved
to the number of bin corresponding to the current mask length m if its SSRC
in
matches the table, key under the masking operation and otherwise is
discarded.

To obtain the estimate of the group size is given by number of session members L, the
following formula is used:

L = n
* 2**m.

The algorithm described attempts SUM from i=0 to keep i=31 of B(i) * (2**i)

Where B(i) is the value number of m to SSRC identifiers in bin i. Note that this
formula counts senders only once since they are all represented in
bin 0, but multiplies the
smallest possible value without overflowing sampled count of non-senders (receivers) by
the table. This yields sampling factor.

As participants leave the best group size estimate possible for session by sending a given BYE or being timed

Schulzrinne/Casner/Frederick/Jacobson [Page 25]

Internet Draft RTP August 7, 1998

out, their entries are removed from the table size B.

Note that this sampling algorithm MUST NOT be applied and the number of
entries in the table may become too small to SSRC
identifiers that correspond provide a reasonable
statistical estimate. When this occurs, it is necessary to senders because otherwise decrease
the
calculation number of bits in the RTCP bandwidth when we_sent is true would be
inaccurate. The mask so that additional SSRC identifiers for senders MUST always
will be added to
the table when first received and not removed from kept. It is recommended that the table when mask be decreased by one
when:

L/(2**m) < B/4

When the mask size is extended.

For each compound RTCP packet received, reduced from m to m-1, all the value SSRC identifiers
remain in their current bins. Thus the estimate of avg_rtcp_sz is
updated: avg_rtcp_sz = (1/16)*packet_size + (15/16)* avg_rtcp_sz,
where packet_size is the size number of
session members is not immediately affected by the RTCP change in mask
size. When a packet just received.

6.3.4 Receiving arrives from an RTCP BYE packet

If the received packet SSRC that is an RTCP BYE packet, the currently in some
bin x where x<m, that SSRC identifier is checked
against the member table. If present, moved from bin x to bin m,
reducing the entry estimate. When a BYE packet is removed received from a
participant or the
table, participant is timed out, and the value for members is decremented by 1. The participant's
SSRC is
then checked against the sender table. If present, exists in the entry membership table, that SSRC identifier is removed
from its bin. Thus the table, and the value for senders is decremented by
1.

If an SSRC sampling algorithm is in use contributions from higher bins fade away as described in the previous

Schulzrinne/Casner/Frederick/Jacobson [Page 28]

Internet Draft RTP December 5, 1997

section, then when the number
bin m acquires a more complete list of entries in the member table falls
below B/2, the mask SHOULD be reduced by 1 bit unless m is already
zero. Note SSRC identifiers that this will cause
now be kept because of the group size estimate to drop by 1/
2. reduced mask.

6.3 RTCP Packet Send and Receive Rules

The estimate will eventually converge rules for how to the correct value as SSRC
identifiers which did not previously match the key under masking, send, and
now do, are added to the table.

Furthermore, to make the transmission rate of RTCP packets more
adaptive what to changes in group membership, the following "reverse
reconsideration" algorithm SHOULD be executed do when receiving an RTCP
packet are outlined here. To execute these rules, a BYE session
participant must maintain several pieces of state:

tp: the last time an RTCP packet is
received:

o The value for tn is updated according to was transmitted;

tc: the following
formula: tn = tc + (members/pmembers)(tn - tc).

o The value for tp is updated according current time;

tn: the following formula:
tp = tc - (members/pmembers)(tc - tp).

o The next RTCP packet is rescheduled for scheduled transmission at time
tn, which is now earlier.

o The value of pmembers is set equal to members.

6.3.5 Timing Out an SSRC

At occassional intervals, RTCP packet;

pmembers: the user MUST check to see if any estimated number of session members at time tp

members: the
other users timeout. To do this, most current estimate for the user computes number of session members;

senders: the deterministic
calculated interval (without most current estimate for the randomization factor) Td. Any other
session member who has not sent a packet since time tc - MTd (M is number of senders in the timeout multiplier, and defaults to 5) is timed out.
session;

rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth that
will be used for RTCP packets by all members of this session, in
octets per second. This means should be 5% of the "session bandwidth"
parameter supplied to the application at startup.

we_sent: Flag that their SSRC is removed from true if the member list, application has sent data since the
2nd previous RTCP report was transmitted.

Schulzrinne/Casner/Frederick/Jacobson [Page 26]

Internet Draft RTP August 7, 1998

avg_rtcp_size: The average compound RTCP packet size, in octets, over
all RTCP packets sent and members is
decremented received by 1. A similar check this participant.

initial: Flag that is performed on the sender list.
Any member on true if the sender list who application has not yet sent an RTP packet since
time tc - T (note the absence
RTCP packet.

Many of these rules make use of the M factor) "calculated interval" between
packet transmissions. This interval is removed described in the following
section.

6.3.1 Computing the RTCP transmission interval

To maintain scalability, the average interval between packets from a
session participant should scale with the
sender list, and senders group size. This interval
is called the calculated interval. It is decremented obtained by 1.

The user SHOULD perform this check every time an RTCP packet combining a
number of any
type is received. The user MAY perform the check less frequently, but
it MUST be done at least once between RTCP packet transmissions from the user.

As pieces of state described in the previous section, if an SSRC sampling algorithm above. The calculated
interval T is in use then when determined as follows:

1. If there are any senders (senders > 0) in the session, but
the number of entries in senders is less than 25% of the member table falls
below B/2, membership
(members), the mask SHOULD be reduced by 1 bit unless m interval depends on whether the participant
is already
zero.

6.3.6 Expiration a sender or not (based on the value of transmission timer

Schulzrinne/Casner/Frederick/Jacobson [Page 29]

Internet Draft RTP December 5, 1997

When we_sent). If the packet transmission timer expires,
participant is a sender (we_sent true), the user performs one of constant C is
set to the following operations:

Option A:

o If members mbers, an average RTCP packet size (avg_rtcp_size) divided
by 25% of the RTCP bandwidth (rtcp_bw), and the constant n
is transmitted. The
transmission interval T, including set to the randomization factor, number of senders. If we_sent is
computed. pmembers not true,
the constant C is set to members, tp the average RTCP packet size
divided by 75% of the RTCP bandwidth. The constant n is set
to tc, the number of receivers (members - senders). If the
number of senders is greater than 25%, senders and tn
receivers are treated together. The constant C is set to tc + T. The transmission timer
the total RTCP bandwidth and n is set to expire again
at time tn.

o If members > pmembers, the transmission interval T, including
the randomization factor, is computed. total number
of members.

2. If tp + T is less than
or equal to tc, the participant has not yet sent an RTCP packet (the
variable initial is transmitted. pmembers is set
to members, tp true), the constant Tmin is set to tc, and tn 2.5
seconds, else it is set to tc + T. 5 seconds.

3. The
transmission timer deterministic calculated interval Td is set to expire again at time tn. If tp +
max(Tmin, n*C).

4. The calculated interval T is greater than tc, pmembers is set to members, a number uniformly
distributed between 0.5 and tn 1.5 times the deterministic
calculated interval.

This procedure results in an interval which is set
to tc + T. No random, but which, on
average, gives 25% of the RTCP packet is transmitted. The transmission
timer is set bandwidth to expire at time tn.

Option B:

o The transmission interval T, including senders, and 75% to
receivers.

Schulzrinne/Casner/Frederick/Jacobson [Page 27]

Internet Draft RTP August 7, 1998

6.3.2 Initialization

Upon joining the randomization
factor, is computed.

o If session, the participant initializes tp + T is less than or equal to tc, an RTCP packet is
transmitted. 0, tc to
0, senders to 0, pmembers is set to members, tp is set 1, members to tc, 1, we_sent to false,
rtcp_bw to 5% of the session bandwidth, initial to true, and
tn is set
avg_rtcp_size to tc + T. the size of the very first packet constructed by the
application. The calculated interval T is then computed, and the
first packet is scheduled for time tn = T. This means that a
transmission timer is set to expire
again which expires at time tn. If tp + T is greater than tc, pmembers is set
to members, and tn is set to tc + T. No Note that an
application MAY use any desired approach for implementing this timer.

The participant adds their own SSRC to the member table.

6.3.3 Receiving an RTP or non-BYE RTCP packet

When an RTP or RTCP packet is
transmitted. The transmission timer is set to expire at time
tn.

Option C:

o Option B received from a participant whose SSRC
is executed for not in the first RTCP packet.

o Option A member table, the SSRC is executed for all subsequent packets.

Users SHOULD use Option B. Users MAY use options C added to the table, and A. Option B
provides the best protection against RTCP
value for members is updated.

When an RTP packet floods is received from a participant whose SSRC is not
in the event
of simultaneous joins or when network partitions heal.

If an RTCP packet sender table, the SSRC is transmitted (using any of added to the above options), table, and the value of initial
for senders is set to FALSE. Furthermore, updated.

For each compound RTCP packet received, the value of
avg_rtcp_sz avg_rtcp_size is
updated: avg_rtcp_sz avg_rtcp_size = (1/16)*packet_size + (15/16)*
avg_rtcp_sz, avg_rtcp_size,
where packet_size is the size of the RTCP packet just
transmitted.

Schulzrinne/Casner/Frederick/Jacobson [Page 30]

Internet Draft RTP December 5, 1997

6.3.7 Transmitting a received.

6.3.4 Receiving an RTCP BYE packet

When a user wishes to leave a session, a

Except as described in Section 6.3.7 for the case when an RTCP BYE packet is transmitted
to
inform the other users of be transmitted, if the event. In order to avoid a flood of received packet is an RTCP BYE
packets when many users leave packet, the system, a client MUST implement
SSRC is checked against the
following algorithm if member table. If present, the number of members entry is more than 50 when the
user chooses to leave:

o When the user decides to leave
removed from the system, tp is reset to tc, table, and the current time, value for members and pmembers are initialized to 1,
initial is set to 1, we_sent updated. The
SSRC is set to 0, senders then checked against the sender table. If present, the entry
is set to 0, removed from the table, and avg_rtcp_sz the value for senders is set updated.

Furthermore, to make the size transmission rate of RTCP packets more
adaptive to changes in group membership, the BYE packet. The
calculated interval T is computed. The following "reverse
reconsideration" algorithm SHOULD be executed when a BYE packet is then
scheduled
received:

o The value for time tn is updated according to the following
formula: tn = tc + T. (members/pmembers)(tn - tc).

o Every time a BYE packet from another user is received, members
is incremented by 1. members The value for tp is NOT incremented when other updated according the following formula:
tp = tc - (members/pmembers)(tc - tp).

o The next RTCP
packets or RTP packets are received, but only packet is rescheduled for BYE packets. transmission at time

Schulzrinne/Casner/Frederick/Jacobson [Page 28]

Internet Draft RTP August 7, 1998

tn, which is now earlier.

o Transmission The value of pmembers is set equal to members.

This algorithm does not prevent the BYE packet then follows the rules group size estimate from
incorrectly dropping to zero for
transmitting a regular RTCP packet, as above. Option B SHOULD
be used.

This allows BYE packets short time when most participants
of a large session leave at once but some remain. The algorithm does
make the estimate return to be sent right away, yet controls their
total bandwidth usage. In the worst case, this could cause RTCP
control packets to use twice the bandwidth as normal (10%) - 5% for
non BYE RTCP packets correct value more rapidly. This
situation is unusual enough and 5% for BYE.

A client which does not want to wait for the above mechanism to allow
them to transmit consequences are sufficiently
harmless that this problem is deemed only a BYE packet MAY leave secondary concern.

6.3.5 Timing Out an SSRC

At occassional intervals, the group without sending a
BYE at all. They will eventually be timed out by participant MUST check to see if any of
the other group
members.

When participants time out. To do this, the group size estimate members is less than 50 when participant computes
the user
decides to leave, deterministic calculated interval (without the user MAY send randomization
factor) Td. Any other session member who has not sent a BYE packet immediately.
Alternatively, since
time tc - MTd (M is the user MAY choose timeout multiplier, and defaults to implement 5) is
timed out. This means that their SSRC is removed from the above BYE backoff
algorithm.

In either case, a client which never sent an RTP or RTCP packet MUST
NOT send a BYE packet when they leave member
list, and members is updated. A similar check is performed on the group.

6.3.8 Updating we_sent

The variable we_sent contains TRUE if
sender list. Any member on the user sender list who has not sent an RTP
packet
recently, false otherwise. This determination is made by using since time tc - 2T (within the
same mechanisms for managing last two RTCP report intervals)
is removed from the sender list, and senders table. When the user first
sends an RTP packet, they add themselves to the sender table. Every
time another RTP packet is sent, the updated.

If any members time of out, the reverse reconsideration algorithm
described in Section 6.3.4 SHOULD be performed.

The participant MUST perform this check at least once per RTCP
transmission interval.

6.3.6 Expiration of that

Schulzrinne/Casner/Frederick/Jacobson [Page 31]

Internet Draft RTP December 5, 1997 transmission timer

When the packet is maintained in transmission timer expires, the table. The normal sender timeout
algorithm participant performs
one of the following operations:

Option A ("conditional reconsideration"):

o If members is then applied less than or equal to the user - if pmembers, an RTP RTCP packet has not been
transmitted since time tc -
is transmitted. The transmission interval T, including the user removes themselves from the
sender table, decrements the sender count, and sents we_sent to
false. Whenever an RTP packet
randomization factor, is sent, we_sent computed. pmembers is set to true.

6.3.9 Allocation of source description bandwidth

This specification defines several source description (SDES) items in
addition members,
tp is set to the mandatory CNAME item, such as NAME (personal name) tc, and EMAIL (email address). It also provides a means tn is set to define new
application-specific RTCP packet types. Applications should exercise
caution in allocating control bandwidth tc + T. The transmission
timer is set to this additional
information because it will slow down the rate expire again at which reception
reports and CNAME are sent, thus impairing time tn.

o If members is greater than pmembers, the performance of transmission interval
T, including the
protocol. It randomization factor, is recommended that no more computed. If tp + T
is less than 20% of the RTCP
bandwidth allocated or equal to a single participant be used tc, an RTCP packet is transmitted.
pmembers is set to carry the
additional information. Furthermore, it members, tp 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 set to
their utility. Rather tc, and tn is set to
tc + T. The transmission timer is set to expire again at time

Schulzrinne/Casner/Frederick/Jacobson [Page 29]

Internet Draft RTP August 7, 1998

tn. If tp + T is greater than estimate these fractions dynamically, it tc, pmembers 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 set to send only CNAME, NAME
and EMAIL members,
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 tn is set to tp + T. No RTCP interval, an RR packet and an SDES packet with is transmitted. The
transmission timer is set to expire at time tn.

Option B ("unconditional reconsideration"):

o The transmission interval T is computed, including the CNAME item would be sent. For
randomization factor and a small session
operating at factor e-3/2=1.21828 times the minimum interval, that would be every 5 seconds on
rtcp_bw to compensate for the average. Every third interval (15 seconds), one extra item would
be included in fact that the SDES packet. Seven out of eight times this would
be unconditional
reconsideration algorithm converges to a value below the NAME item,
intended average.

o If tp + T is less than or equal to tc, an RTCP packet is
transmitted. tp is set to tc, and every eighth tn is set to tc + T. The
transmission timer is set to expire again at 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, tn. If tp + T
is greater than tc, pmembers is set to members, and tn is set
to tp + T. No RTCP packet is transmitted. The transmission
timer is set to expire at time tn.

Option C ("hybrid reconsideration"):

o Option B is executed for example in a
multimedia conference composed of an RTP session the first RTCP packet.

o Option A is executed for each medium, all subsequent packets.

Implementationss SHOULD use Option B. Implementations MAY use options
C and A. Option B provides the
additional SDES information might be sent best protection against RTCP packet
floods in only one RTP session.
The other sessions would carry only the CNAME item. In particular,
this approach should be applied to the multiple sessions event of a layered
encoding scheme (see Section 2.4).

6.4 Sender and Receiver Reports

RTP receivers provide reception quality feedback using simultaneous joins or when network partitions
heal.

If an RTCP report
packets which may take one packet is transmitted (using any of two forms depending upon whether or not

Schulzrinne/Casner/Frederick/Jacobson [Page 32]

Internet Draft RTP December 5, 1997 the receiver above options),
the value of initial is also a sender. The only difference between set to FALSE. Furthermore, the sender
report (SR) and receiver report (RR) forms, besides the packet type
code, value of
avg_rtcp_size is that the sender report includes a 20-byte sender information
section for use by active senders. The SR updated: avg_rtcp_size = (1/16)*packet_size +
(15/16)* avg_rtcp_size, where packet_size is issued if a site has
sent any data packets during the interval since issuing the last
report or the previous one, otherwise size of the RR RTCP
packet just transmitted.

6.3.7 Transmitting a BYE packet

When a participant wishes to leave a session, a BYE packet is issued.

Both
transmitted to inform the SR and RR forms include zero or more reception report
blocks, one for each other participants of the synchronization sources from which this
receiver has received RTP data event. In order
to avoid a flood of BYE packets since the last report. Reports
are not issued for contributing sources listed in when many participants leave the CSRC list. Each
reception report block provides statistics about
system, a participant MUST execute the data received
from following algorithm if the particular source indicated in that block. Since a maximum
number of 31 reception report blocks will fit in an SR or RR packet,
additional RR packets may be stacked after members is more than 50 when the initial SR or RR
packet as needed participant chooses to contain
leave. This algorithm usurps the reception reports for all sources
heard during normal role of the interval since members variable
to count BYE packets instead:

o When the last report.

The next sections define participant decides to leave the formats of system, tp is reset
to tc, 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 current time, members and mixers is given in
Section 7.

6.4.1 SR: Sender report RTCP packet pmembers are initialized

Schulzrinne/Casner/Frederick/Jacobson [Page 33] 30]

Internet Draft RTP December 5, 1997

to 1, initial is set to 1, we_sent is set to 0, senders is set
to 0, and avg_rtcp_size is set to the size of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP timestamp, most significant word | sender
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's the BYE packet.
The calculated interval T is computed. The BYE packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC is then
scheduled for time tn = tc + T.

o Every time a BYE packet from another participant is received,
members is incremented by 1 regardless of first source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost | cumulative number whether that
participant exists in the member table or not, and when SSRC
sampling is in use, regardless of whether the BYE SSRC matches
the key or not. members is NOT incremented when other RTCP
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 or RTP packets are received, but only for BYE packets.

o Transmission 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:

version (V): 2 bits
Identifies the version of RTP, which is BYE packet then follows the same in rules for
transmitting a regular RTCP packets packet, as in RTP data packets. The version defined by this
specification is two (2).

padding (P): 1 bit

Schulzrinne/Casner/Frederick/Jacobson [Page 34]

Internet Draft RTP December 5, 1997

If above. Option B SHOULD
be used.

This allows BYE packets to be sent right away, yet controls their
total bandwidth usage. In the padding bit is set, worst case, this individual could cause RTCP packet contains
some additional padding octets at
control packets to use twice the end which are bandwidth as normal (10%) -- 5% for
non BYE RTCP packets and 5% for BYE.

A participant that does not part of
the control information but are included in want to wait for the length field.
The last octet above mechanism to
allow transmission of a BYE packet MAY leave the padding is group without
sending a count of how many padding
octets should be ignored, including itself (it BYE at all. That participant will eventually be a
multiple of four). Padding may be needed timed out
by some encryption
algorithms with fixed block sizes. In a compound RTCP packet,
padding should only be required on the last individual packet
because other group members.

If the compound packet group size estimate members is encrypted as a whole. Thus, less than 50 when the
padding bit would be set only on
participant decides to leave, the last individual packet.

reception report count (RC): 5 bits
The number of reception report blocks contained in this packet.
A value of zero is valid. participant MAY send a BYE packet type (PT): 8 bits
Contains
immediately. Alternatively, the constant 200 participant MAY choose to identify this as an RTCP SR packet.

length: 16 bits
The length of this RTCP packet in 32-bit words minus one,
including execute the header and any padding. (The offset of one makes
zero a valid length and avoids a possible infinite loop in
scanning
above BYE backoff algorithm.

In either case, a compound participant which never sent an RTP or RTCP packet, while counting 32-bit words
avoids a validity check for packet
MUST NOT send a multiple of 4.)

SSRC: 32 bits BYE packet when they leave the group.

6.3.8 Updating we_sent

The synchronization source identifier variable we_sent contains true if the participant has sent an RTP
packet recently, false otherwise. This determination is made by using
the same mechanisms for managing the originator of this senders table and sending SR packet.

The second section,
packets. If the sender information, participant sends an RTP packet when we_sent is 20 octets long
false, it adds itself to the sender table and sets we_sent to true.
Every time another RTP packet 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 sent, 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 transmission 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
the session instead. This packet is assumed to be less than 68 years,
so maintained in the high bit will be zero. It table. The normal sender timeout
algorithm is permissible then applied to use the
sampling clock to estimate elapsed wallclock time. A sender that participant -- if an RTP packet has no notion of wallclock or elapsed
not been transmitted since time may set tc - 2T, the NTP participant removes
itself from the sender table, decrements the sender count, and sets
we_sent to false.

Schulzrinne/Casner/Frederick/Jacobson [Page 35] 31]

Internet Draft RTP December 5, 1997

timestamp to zero.

RTP timestamp: 32 bits
Corresponds to the same time as the NTP timestamp (above), but August 7, 1998

6.3.9 Allocation of source description bandwidth

This specification defines several source description (SDES) items in
addition to the same units and with the same random offset mandatory CNAME item, such as the RTP
timestamps in data packets. This correspondence may be used for
intra- NAME (personal name)
and inter-media synchronization for sources whose NTP
timestamps are synchronized, and may be used by media-
independent receivers EMAIL (email address). It also provides a means to estimate the nominal RTP clock
frequency. Note that define new
application-specific RTCP packet types. Applications should exercise
caution in most cases this timestamp will not be
equal allocating control bandwidth to the RTP timestamp in any adjacent data packet. Rather, this additional
information because it is calculated from the corresponding NTP timestamp using the
relationship between will slow down the RTP timestamp counter rate at which reception
reports and real time as
maintained by periodically checking CNAME are sent, thus impairing the wallclock time at a
sampling instant.

sender's packet count: 32 bits
The total number performance of RTP data packets transmitted by the sender
since starting transmission up until the time this SR packet was
generated. The count
protocol. It is reset if the sender changes its SSRC
identifier.

sender's octet count: 32 bits
The total number recommended that no more than 20% 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 RTCP
bandwidth allocated to a single participant be used to estimate the average
payload data rate.

The third section contains zero or more reception report blocks
depending on carry the number
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 other sources heard by this sender since the last report. Each reception bandwidth according to
their utility. Rather than estimate these fractions dynamically, it
is recommended that the percentages be translated statically into
report block conveys statistics interval counts based 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 typical length of the source an item.

For example, an application may be designed to which send only CNAME, NAME
and EMAIL and not any others. NAME might be given much higher
priority than EMAIL because the information NAME would be displayed continuously
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 application's user interface, whereas EMAIL would be displayed
only when requested. At every RTCP interval, an RR packet was sent, expressed as a fixed
point number and an SDES
packet with the binary point CNAME item would be sent. For a small session
operating at the left edge of the
field. (That is equivalent to taking the integer part after
multiplying minimum interval, that would be every 5 seconds on
the loss fraction by 256.) This fraction is defined
to average. Every third interval (15 seconds), one extra item would
be included in the number SDES packet. Seven out of packets lost divided by eight times this would
be the number of

Schulzrinne/Casner/Frederick/Jacobson [Page 36]

Internet Draft RTP December 5, 1997

packets expected, as defined in NAME item, and every eighth time (2 minutes) it would be the next paragraph. An
implementation is shown
EMAIL item.

When multiple applications operate in Appendix A.3. If 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 loss is
negative due to duplicates,
additional SDES information might be sent in only one RTP session.
The other sessions would carry only the fraction lost is set CNAME item. In particular,
this approach should be applied to zero.
Note that the multiple sessions of a receiver cannot tell whether any layered
encoding scheme (see Section 2.4).

6.4 Sender and Receiver Reports

RTP receivers provide reception quality feedback using RTCP report
packets were lost
after the last which may take one received, 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 there will be no reception the sender report block issued for includes a source 20-byte sender information
section for use by active senders. The SR is issued if all packets from that source a site has
sent any data packets 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 issuing the beginning of reception. This number last
report or the previous one, otherwise the RR is
defined to be issued.

Schulzrinne/Casner/Frederick/Jacobson [Page 32]

Internet Draft RTP August 7, 1998

Both the number SR and RR forms include zero or more reception report
blocks, one for each of packets expected less the number of
packets actually received, where the number of packets received
includes any synchronization sources from 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 this
receiver has received RTP data packets
expected is defined to be since the extended last sequence number
received, as defined next, less the initial sequence number
received. This may be calculated as shown report. Reports
are not issued for contributing sources listed in Appendix A.3.

extended highest sequence number received: 32 bits
The low 16 bits contain the highest sequence number received in
an RTP CSRC list. Each
reception report block provides statistics about the data packet received
from source SSRC_n, and the most significant
16 bits extend particular source indicated in that sequence number with the corresponding count block. Since a maximum
of sequence number cycles, which 31 reception report blocks will fit in an SR or RR packet,
additional RR packets may be maintained according to
the algorithm in Appendix A.1. Note that different receivers
within stacked after the same session will generate different extensions initial SR or RR
packet as needed to contain the sequence number if their start times differ significantly.

interarrival jitter: 32 bits
An estimate of reception reports for all sources
heard during the statistical variance of interval since the RTP data packet
interarrival time, measured in timestamp units and expressed as
an unsigned integer. last report.

The interarrival jitter J is defined to be next sections define the mean deviation (smoothed absolute value) formats of the difference D two reports, how they may
be extended 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 profile-specific manner if an application requires
additional feedback information, and how the receiver's clock at the
time reports may be used.
Details of arrival, measured in the same units.

If Si is the RTP timestamp from packet i, reception reporting by translators and Ri mixers is the time of
arrival given in RTP timestamp units for packet i, then for two packets i
and j, D may be expressed as D(i,j) = (R_j - R_i) - (S_j - S_i) =
(R_j - S_j) - (R_i - S_i)

The interarrival jitter is calculated continuously as each data
Section 7.

6.4.1 SR: Sender report RTCP packet i is received from source SSRC_n, using this difference D for

Schulzrinne/Casner/Frederick/Jacobson [Page 37] 33]

Internet Draft RTP December 5, 1997

that packet and the previous August 7, 1998

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 i-1 in order count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of arrival (not
necessarily in sequence), according to the formula J_i = J_i-1 +
(|D(i-1,i)| - J_i-1)/16
Whenever a reception first source) | report is issued, the current value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost | cumulative number of J is
sampled.

The packets lost | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter calculation is prescribed here to allow profile-
independent monitors to make valid interpretations |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC 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 second source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The sender report packet consists of convergence
[11]. A sample implementation three sections, possibly
followed by a fourth profile-specific extension section if defined.
The first section, the header, is shown in Appendix A.8.

last SR timestamp (LSR): 32 bits 8 octets long. The middle 32 fields have the
following meaning:

version (V): 2 bits out
Identifies the version of 64 in RTP, which is the NTP timestamp (as explained same in Section 4) received RTCP packets
as part of in RTP data packets. The version defined by this
specification is two (2).

padding (P): 1 bit

Schulzrinne/Casner/Frederick/Jacobson [Page 34]

Internet Draft RTP August 7, 1998

If the most recent padding bit is set, this individual RTCP sender
report (SR) packet from source SSRC_n. If no SR has been
received yet, contains
some additional padding octets at the field is set to zero.

delay since last SR (DLSR): 32 bits
The delay, expressed in units end which are not part of 1/65536 seconds, between
receiving
the control information but are included in the length field.
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, octet of the DLSR field padding 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 a count of how many padding
octets should be ignored, including itself (it will be a
multiple of four). Padding may be needed by recording
the time A when this reception report some encryption
algorithms with fixed block sizes. In a compound RTCP packet,
padding is received. It
calculates only required on one individual packet because the total round-trip time A-LSR using
compound packet is encrypted as a whole for the method in
Section 9.1. Thus, padding MUST only be added to the last SR
timestamp (LSR) field,
individual packet, and then subtracting this field if padding is added to leave that packet, the
round-trip propagation delay as (A- LSR - DLSR).
padding bit MUST be set only on that packet. This is illustrated convention
aids the header validity checks described in Fig. 2.

This may be used as an approximate measure Appendix A.2 and
allows detection of distance to cluster
receivers, although packets from some links have very asymmetric delays.

6.4.2 RR: Receiver report RTCP early implementations that
incorrectly set the padding bit on the first individual packet

Schulzrinne/Casner/Frederick/Jacobson [Page 38]

Internet Draft RTP December 5, 1997

[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
and add padding to the last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) | individual packet.

reception report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |

Schulzrinne/Casner/Frederick/Jacobson [Page 39]

Internet Draft RTP December 5, 1997

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ count (RC): 5 bits
The format number of the receiver reception report (RR) packet is the same as that blocks contained in this packet.
A value of
the SR packet except that the zero is valid.

packet type field contains (PT): 8 bits
Contains the constant
201 and the five words 200 to identify this as an RTCP SR packet.

length: 16 bits
The length of sender information are omitted (these are this RTCP packet in 32-bit words minus one,
including the NTP and RTP timestamps header and sender's packet any padding. (The offset of one makes
zero a valid length and octet counts). 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
remaining fields have the same meaning as synchronization source identifier for the originator of this
SR packet.

An empty RR packet (RC = 0) is put at

The second section, the head of a compound RTCP
packet when there sender information, is no 20 octets long and is
present in every sender report packet. It summarizes the data transmission or reception to report.

6.4.3 Extending
transmissions from this sender. The fields have the sender and receiver reports

A profile should define profile- or application-specific extensions
to following
meaning:

NTP timestamp: 64 bits
Indicates the sender wallclock time (see Section 4) when this report and receiver if there is additional information
was sent so that should be reported regularly about the sender or receivers. This
method should it may be used in preference to defining another RTCP packet
type because it requires less overhead:

o fewer octets combination with timestamps
returned in the packet (no RTCP header or SSRC field);

o simpler and faster parsing because applications running under
that profile would be programmed reception reports from other receivers to always measure
round-trip propagation to those receivers. Receivers should
expect that the extension
fields in the directly accessible location after measurement accuracy of the reception
reports.

If additional sender information is required, it should timestamp may 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
limited to far less than the existing array resolution of reception report blocks; that is, the number NTP timestamp.
The measurement uncertainty of blocks would be indicated by the RC field.

6.4.4 Analyzing sender and receiver reports

It timestamp is expected that reception quality feedback will be useful not
only for the sender indicated as

Schulzrinne/Casner/Frederick/Jacobson [Page 35]

Internet Draft RTP August 7, 1998

it may not be known. On a system that has no notion of
wallclock time but also for other receivers and third-party
monitors. The does have some system-specific clock such as
"system uptime", a sender may modify its transmissions based on the
feedback; receivers can determine whether problems are local,
regional or global; network managers may MAY use profile-independent
monitors that receive only the RTCP packets and not the corresponding
RTP data packets clock as a reference to evaluate the performance of their networks for
multicast distribution.

Cumulative counts are
calculate relative NTP timestamps. It is important to choose a
commonly used in both the sender information and
receiver report blocks clock so that differences may be calculated between
any two reports to make measurements over both short and long time
periods, and if separate implementations are used
to provide resilience against produce the loss individual streams of a report. The

Schulzrinne/Casner/Frederick/Jacobson [Page 40]

Internet Draft RTP December 5, 1997

difference between multimedia session, all
implementations will use the last two reports received can be used same clock. These relative NTP
timestamps are assumed to
estimate have a reference time less than 68
years in the recent quality past, so the high bit will be zero to serve as an
indication of relative timestamps. A sender that has no notion
of wallclock or elapsed time may set the distribution. The NTP timestamp is
included so that rates may be calculated from these differences over to zero.

RTP timestamp: 32 bits
Corresponds to the interval between two reports. Since that same time as the NTP timestamp is (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
of receivers to estimate the nominal RTP clock rate for
frequency. Note that in most cases this timestamp will not be
equal to the RTP timestamp in any adjacent data encoding, packet. Rather,
it is possible to implement
encoding- and profile-independent quality monitors.

An example calculation is calculated from the packet loss rate over corresponding NTP timestamp using the interval
relationship between two reception reports. The difference in the cumulative
number of packets lost gives RTP timestamp counter and real time as
maintained by periodically checking the number lost during that interval. wallclock time at a
sampling instant.

sender's packet count: 32 bits
The difference in the extended last sequence numbers received gives
the total number of RTP data packets expected during transmitted by the interval. The ratio of
these two is sender
since starting transmission up until the time this SR packet loss fraction over the interval. This ratio
should equal the fraction lost field was
generated. The count is reset 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. 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 received is by the number of packets expected minus sender since
starting transmission up until the number lost. time this SR packet was
generated. The number of
packets expected may also count is reset if the sender changes its SSRC
identifier. This field can be used to judge estimate the statistical validity average
payload data rate.

The third section contains zero or more reception report blocks
depending on the number of any loss estimates. For example, 1 out other sources heard by this sender since
the last report. Each reception report block conveys statistics on
the reception of 5 RTP packets lost has from a
lower significance than 200 out 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

Schulzrinne/Casner/Frederick/Jacobson [Page 36]

Internet Draft RTP August 7, 1998

The SSRC identifier of 1000.

From the sender information, a third-party monitor can calculate source to which the
average payload information in
this reception report block pertains.

fraction lost: 8 bits
The fraction of RTP data rate and packets from source SSRC_n lost since
the average previous SR or RR packet rate over an
interval without receiving was sent, expressed as a fixed
point number with the data. Taking binary point at the ratio left edge of the two
gives
field. (That is equivalent to taking the integer part after
multiplying the average payload size. If it can be assumed that packet loss fraction by 256.) This fraction is independent of packet size, then defined
to be the number of packets received lost divided by
a particular receiver times the average payload size (or the
corresponding packet size) gives number of
packets expected, as defined in the apparent throughput available to
that receiver.

In addition to next paragraph. An
implementation is shown in Appendix A.3. If the cumulative counts which allow long-term packet loss measurements using differences between reports, is
negative due to duplicates, the fraction lost field provides a short-term measurement from is set to zero.
Note that a single report.
This becomes more important as receiver cannot tell whether any packets were lost
after the size of a session scales up enough last one received, and that reception state information might not there will be kept no reception
report block issued for a source if all receivers
or packets from that source
sent during the last reporting interval between reports becomes long enough that only one
report might have been received from a particular receiver. lost.

cumulative number of packets lost: 24 bits
The interarrival jitter field provides a second short-term measure total number of
network congestion. Packet loss tracks persistent congestion while RTP data packets from source SSRC_n that
have been lost since the jitter measure tracks transient congestion. The jitter measure
may indicate congestion before it leads beginning of reception. This number is
defined to packet loss. Since be the
interarrival jitter field is only a snapshot number of packets expected less the jitter at number of
packets actually received, where the
time number of a report, it packets received
includes any which are late or duplicates. Thus packets that
arrive late are not counted as lost, and the loss 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/Casner/Frederick/Jacobson [Page 41]

Internet Draft RTP December 5, 1997

6.5 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 |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
negative if there are duplicates. The SDES packet is a three-level structure composed of a header and
zero or more chunks, each of number of which packets
expected is composed of items describing defined to be the source identified extended last sequence number
received, as defined next, less the initial sequence number
received. This may be calculated as shown in that chunk. Appendix A.3.

extended highest sequence number received: 32 bits
The items are described
individually in subsequent sections.

version (V), padding (P), length:
As described for the SR packet (see Section 6.4.1).

packet type (PT): 8 low 16 bits
Contains contain the constant 202 to identify this as highest sequence number received in
an RTCP SDES
packet. RTP data packet from source count (SC): 5 SSRC_n, and the most significant
16 bits
The extend that sequence 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 with the SSRC/CSRC. Each
chunk starts on a 32-bit boundary. Each item consists of an 8-bit
type field, an 8-bit octet corresponding count describing the length
of sequence number cycles, which may be maintained according to
the text
(thus, not including this two-octet header), and the text itself. algorithm in Appendix A.1. Note that different receivers
within 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 same session will generate different extensions to
the UTF-8 encoding specified in RFC
2044. US-ASCII is a subset sequence number if their start times differ significantly.

interarrival jitter: 32 bits
An estimate of this encoding the statistical variance of the RTP data packet
interarrival time, measured in timestamp units and requires no
additional encoding. expressed as
an unsigned integer. The presence of multi-octet encodings interarrival jitter J is
indicated by setting defined to be
the most significant bit mean deviation (smoothed absolute value) of a character the difference D
in packet spacing at the receiver compared to the sender for a
value
pair of one. 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

Schulzrinne/Casner/Frederick/Jacobson [Page 42] 37]

Internet Draft RTP December 5, 1997

Items are contiguous, i.e., items are not individually padded to August 7, 1998

between 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, packet's RTP timestamp and the first of which is
interpreted as an item type of zero to denote receiver's clock at the end
time of arrival, measured in the list.
No length octet follows the null item type octet, but additional null
octets are included if needed to pad until the next 32-bit boundary.
Note that this padding same units.

If Si is separate the RTP timestamp from that indicated by packet i, and Ri is the P bit time of
arrival in the RTCP header. A chunk with zero items (four null octets) RTP timestamp units for packet i, then for two packets i
and j, D may be expressed as D(i,j) = (R_j - R_i) - (S_j - S_i) =
(R_j - S_j) - (R_i - S_i)

The interarrival jitter is
valid but useless.

End systems send one SDES calculated continuously as each data
packet containing their own i is received from source
identifier (the same as SSRC_n, using this difference D for
that packet and the SSRC previous packet i-1 in order of arrival (not
necessarily in sequence), according to the fixed RTP header). A mixer
sends one SDES packet containing formula J_i = J_i-1 +
(|D(i-1,i)| - J_i-1)/16
Whenever a chunk for each contributing source
from which it reception report is receiving SDES information, or multiple complete
SDES packets in issued, the format above if there are more than 31 such
sources (see Section 7). current value of J is
sampled.

The SDES items currently defined are described in the next sections.
Only the CNAME item jitter calculation is mandatory. Some items shown prescribed 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 allow profile-
independent applications. Additional items may be defined in a
profile by registering monitors to make valid interpretations of reports coming
from different implementations. This algorithm is the type numbers with IANA.

6.5.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 optimal first-
order estimator and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The CNAME identifier has the following properties:

o Because the randomly allocated SSRC identifier may change if gain parameter 1/16 gives a
conflict is discovered or if good noise
reduction ratio while maintaining a program reasonable rate of convergence
[12]. A sample implementation is restarted, shown in Appendix A.8.

last SR timestamp (LSR): 32 bits
The middle 32 bits out of 64 in the CNAME
item is required to provide NTP timestamp (as explained
in Section 4) received as part of the binding most recent RTCP sender
report (SR) packet from source SSRC_n. If no SR has been
received yet, the SSRC
identifier field is set to an identifier for 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 that remains
constant.

o Like the SSRC identifier, SSRC_n and sending this
reception report block. If no SR packet has been received yet
from SSRC_n, 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 DLSR field is set of related RTP sessions, to zero.

Let SSRC_r denote the CNAME should
be fixed for that participant.

Schulzrinne/Casner/Frederick/Jacobson [Page 43]

Internet Draft RTP December 5, 1997

o To facilitate third-party monitoring, receiver issuing this receiver report. Source
SSRC_n can compute the CNAME should be
suitable for either a program or a person round propagation delay to locate the source.

Therefore, SSRC_r by recording
the CNAME should be derived algorithmically and not
entered manually, time A 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" this reception report block is either the fully qualified
domain name of received. It
calculates the host from which total round-trip time A-LSR using the real-time data originates,
formatted according last SR
timestamp (LSR) field, and then subtracting this field to leave the rules specified
round-trip propagation delay as (A- LSR - DLSR). This is illustrated
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 Fig. 2.

This may be 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 approximate measure of distance to further
identify the source, or the profile for that application would cluster
receivers, although some links 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.

6.4.2 RR: Receiver report RTCP packet

Schulzrinne/Casner/Frederick/Jacobson [Page 44] 38]

Internet Draft RTP December 5, 1997

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.5.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.5.3 EMAIL: Electronic mail address SDES item August 7, 1998

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 | EMAIL=3 PT=RR=201 | length | email address header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source 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/Casner/Frederick/Jacobson [Page 39]

Internet Draft RTP August 7, 1998

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The email address format of the receiver report (RR) packet is formatted according to RFC 822 [19], for
example, "John.Doe@megacorp.com". 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 EMAIL value
remaining fields have the same meaning as for the SR packet.

An empty RR packet (RC = 0) is expected put at the head of a compound RTCP
packet when there is no data transmission or reception to report.

6.4.3 Extending the sender and receiver reports

A profile SHOULD define profile-specific extensions to the sender
report and receiver report if there is additional information that
needs to be reported regularly about the sender or receivers. This
method SHOULD be used in preference to
remain constant for defining another RTCP packet
type because it requires less overhead:

o fewer octets in the duration of a session.

6.5.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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Schulzrinne/Casner/Frederick/Jacobson [Page 45]

Internet Draft RTP December 5, 1997

The phone number should packet (no RTCP header or SSRC field);

o simpler and faster parsing because applications running under
that profile would be formatted with programmed to always expect the plus sign replacing extension
fields in the
international access code. For example, "+1 908 555 1212" for directly accessible location after the reception
reports.

The extension is a
number fourth section in the United States.

6.5.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 sender- or receiver-report
packet which comes at the application, different degrees of detail are
appropriate end after the reception report blocks, if
any. If additional sender information is required, then for this item. For conference applications, a string like
"Murray Hill, New Jersey" sender
reports it should be included first in the extension section, but for
receiver reports it would not be present. If information about
receivers is to be included, that data may be sufficient, while, for structured as an active
badge system, strings like "Room 2A244, AT&T BL MH" might be
appropriate. The degree array
of detail is left blocks parallel to the implementation
and/or user, but format and content may existing array of reception report blocks;
that is, the number of blocks would be prescribed indicated by a profile.
The LOC value the RC field.

6.4.4 Analyzing sender and receiver reports

It is expected to remain constant that reception quality feedback will be useful not
only for the duration of a
session, except sender but also for mobile hosts.

6.5.6 TOOL: Application 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 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 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 source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A string giving their networks for
multicast distribution.

Cumulative counts are used in both the name sender information and possibly version
receiver report blocks so that differences may be calculated between

Schulzrinne/Casner/Frederick/Jacobson [Page 40]

Internet Draft RTP August 7, 1998

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 application
generating last two reports received can be used to
estimate the stream, e.g., "videotool 1.2". This information recent quality of the distribution. The NTP timestamp is
included so that rates may be
useful calculated from these differences over
the interval between two reports. Since that timestamp is independent
of the clock rate for debugging purposes and the data encoding, it is similar possible to implement
encoding- and profile-independent quality monitors.

An example calculation is the Mailer or Mail-
System-Version SMTP headers. packet loss rate over the interval
between two reception reports. The TOOL value is expected to remain
constant for difference in the duration cumulative
number of packets lost gives the session.

6.5.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 number lost during that interval.
The difference in the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ extended last sequence numbers received gives
the number of packets expected during the interval. The following semantics 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 suggested for this item,
consecutive, but these or
other semantics may otherwise not. The loss rate per second can be explicitly defined
obtained by a profile. dividing the loss fraction by the difference in NTP
timestamps, expressed in seconds. The NOTE item

Schulzrinne/Casner/Frederick/Jacobson [Page 46]

Internet Draft RTP December 5, 1997 number of packets received is intended for transient messages describing
the current state number of packets expected minus the source, e.g., "on the phone, can't talk". Or, during a seminar,
this item might number lost. The number of
packets expected may also be used to convey judge the title 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 talk. It should be
used only to carry exceptional information and should not be included
routinely by all participants because this would slow down sender information, a third-party monitor can calculate the
average payload data rate
at which reception reports and CNAME are sent, thus impairing the
performance average packet rate over an
interval without receiving the data. Taking the ratio of the protocol. In particular, two
gives the average payload size. If it should not can be included
as an item in a user's configuration file nor automatically generated
as in assumed that packet loss
is independent of packet size, then the number of packets received by
a quote-of-the-day.

Since particular receiver times the NOTE item may be important average payload size (or the
corresponding packet size) gives the apparent throughput available to
that receiver.

In addition to display while it is active, the rate at cumulative counts which other non-CNAME items such 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 NAME are transmitted the size of a session scales up enough
that reception state information might not be reduced so that kept for all receivers
or the NOTE item can take interval between reports becomes long enough that part 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 RTCP
bandwidth. When the jitter measure tracks transient message becomes inactive, the NOTE item
should continue congestion. The jitter measure
may indicate congestion before it leads to be transmitted a few times at packet loss. Since the same repetition
rate but with
interarrival jitter field is only a string snapshot of length zero to signal the receivers.
However, receivers should also consider jitter at the NOTE item inactive if
time of a report, it
is not received for may be necessary to analyze a small multiple number of the repetition rate, reports
from one receiver over time or
perhaps 20-30 from multiple receivers, e.g., within

Schulzrinne/Casner/Frederick/Jacobson [Page 41]

Internet Draft RTP August 7, 1998

a single network.

6.5 SDES: Source description RTCP intervals.

6.5.8 PRIV: Private extensions SDES item packet

This item 2
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The SDES packet is used to define experimental a three-level structure composed of a header and
zero or application-specific 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.4.1).

packet type (PT): 8 bits
Contains the constant 202 to identify this as an RTCP SDES
extensions.
packet.

source count (SC): 5 bits
The item contains a prefix consisting number of a length-string
pair, 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 the value string filling the remainder a list of
zero or more items, which carry information about the SSRC/CSRC. Each
chunk starts on a 32-bit boundary. Each item
and carrying consists of an 8-bit
type field, an 8-bit octet count describing the desired information. The prefix length field is 8
bits long. The prefix string is a name chosen by of the person defining text
(thus, not including this two-octet header), and the PRIV item to text itself.
Note that the text can be unique no longer than 255 octets, but this is
consistent with respect the need to other PRIV items this
application might receive. limit RTCP bandwidth consumption.

The application creator might choose text is encoded according to
use the application name plus an UTF-8 encoding specified in RFC
2279 [13]. US-ASCII is a subset of this encoding and requires no
additional subtype identification if
needed. Alternatively, it encoding. The presence of multi-octet encodings is recommended that others choose

Schulzrinne/Casner/Frederick/Jacobson [Page 42]

Internet Draft RTP August 7, 1998

indicated by setting the most significant bit of a name
based on 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 entity they represent, then coordinate first of which is
interpreted as an item type of zero to denote the use end of the
name within that entity. list.
No length octet follows the null item type octet, but additional null
octets are included if needed to pad until the next 32-bit boundary.
Note that this padding is separate from that indicated by the prefix consumes some space within the item's total
length of 255 octets, so P bit
in the prefix should be kept as short RTCP header. 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
possible. This facility and the constrained RTCP bandwidth should not
be overloaded; SSRC in the fixed RTP header). A mixer
sends one SDES packet containing a chunk for each contributing source
from which it is not intended to satisfy all receiving SDES information, or multiple complete
SDES packets in the control
communication requirements of all applications.

Schulzrinne/Casner/Frederick/Jacobson [Page 47]

Internet Draft RTP December 5, 1997 format above if there are more than 31 such
sources (see Section 7).

The SDES PRIV prefixes will not items currently defined are described in the next sections.
Only the CNAME item is mandatory. Some items shown here may be registered by IANA. If some form of useful
only for particular profiles, but the PRIV item proves types are all assigned
from one common space to promote shared use and to simplify profile-
independent applications. Additional items may be of general utility, it should instead be
assigned defined in a regular
profile by registering the type numbers with IANA.

6.5.1 CNAME: Canonical end-point identifier SDES item type registered with IANA so that no
prefix is required. This simplifies use and increases transmission
efficiency.

6.6 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
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ CNAME=1 | length | reason for leaving user and domain name ... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The BYE packet indicates 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.

Schulzrinne/Casner/Frederick/Jacobson [Page 43]

Internet Draft RTP August 7, 1998

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.

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 more sources are no longer
active.

version (V), padding (P), length:
As described the standard ASCII
representation of the host's numeric address on the interface used
for the SR packet (see Section 6.4.1).

packet type (PT): 8 bits
Contains RTP communication. For example, the constant 203 to identify this as standard ASCII
representation of an RTCP BYE
packet.

source count (SC): 5 bits 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 number of SSRC/CSRC identifiers included in this BYE packet.
A count value of zero fully qualified domain
name is valid, more convenient for a human observer and may avoid the need
to send a NAME item in addition, but useless.

The rules 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 when a BYE packet
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 sent are specified in
Section 6.3.7.

If a BYE packet is received by form that a mixer, program such as "finger" or
"talk" could use, i.e., it typically is the mixer forwards login name rather than
the BYE
packet with personal name. The host name is not necessarily identical to the SSRC/CSRC identifier(s) unchanged. If a mixer shuts
down, it should send
one in the participant's electronic mail address.

This syntax will not provide unique identifiers for each source if an
application permits a BYE packet listing all contributing user to generate multiple sources it
handles, as well as its own SSRC identifier. Optionally, the BYE
packet may include from one
host. Such an 8-bit octet count followed by that many octets
of text indicating application would have to rely on the reason for leaving, e.g., "camera malfunction" SSRC to further
identify the source, or "RTP loop detected". The string has the same encoding as that
described profile for SDES. If the string fills the packet that application would have
to specify additional syntax for the next 32-bit
boundary, CNAME identifier.

If each application creates its CNAME independently, the string is resulting
CNAMEs may not null terminated. 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 not, cross-media binding is required, it may be
necessary for the BYE packet CNAME of each tool to be externally configured with
the same value by a coordination tool.

Schulzrinne/Casner/Frederick/Jacobson [Page 48] 44]

Internet Draft RTP December 5, 1997

is padded August 7, 1998

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
lead to non-unique CNAMEs if hosts with null octets 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 next 32-bit boundary. This padding burden is separate from that indicated by the P bit in on the RTCP header.

6.7 APP: Application-defined RTCP packet
translator to translate CNAMEs from private addresses to public
addresses if necessary to keep private addresses from being exposed.

6.5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype
| PT=APP=204 NAME=2 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| common name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

This is recommended that
each APP packet be redefined without the subtype and real 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.4.1).

subtype: 5 bits
May be used as a subtype to allow a set of APP packets to describe the source, e.g., "John Doe,
Bit Recycler, Megacorp". It may be
defined under one unique name, or for in any application-dependent
data.

packet type (PT): 8 bits
Contains form desired by the constant 204 to identify this user.
For applications such as an RTCP APP
packet.

name: 4 octets
A conferencing, this form of name chosen by may be the person defining
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 set duration of APP packets a session. It should not be
relied upon to be unique with respect to other APP packets this application
might receive. The application creator might choose to use the
application name, and then coordinate among all participants in the allocation session.

6.5.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 subtype
values to others who want source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The email address is formatted according to define new packet types RFC 822 [19], for the
application. Alternatively, it
example, "John.Doe@megacorp.com". The EMAIL value is recommended that others
choose a name based on the entity they represent, then
coordinate expected to
remain constant for the use duration of the name within that entity. The name is
interpreted as a sequence of four ASCII characters, with session.

6.5.4 PHONE: Phone number SDES item

Schulzrinne/Casner/Frederick/Jacobson [Page 49] 45]

Internet Draft RTP December 5, 1997

uppercase and lowercase characters treated as distinct.

application-dependent data: variable length
Application-dependent data may or may not appear in an APP
packet. It is interpreted by the application and not RTP itself.
It must be a multiple of 32 bits long. August 7, 1998

0 1 2 3
0 1 2 3 4 5 6 7 RTP Translators and Mixers

In addition to end systems, RTP supports the notion 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 "translators"
and "mixers", which could source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The phone number should be considered as "intermediate systems" at
the RTP level. Although this support adds some complexity to formatted with the
protocol, plus sign replacing the need
international access code. For example, "+1 908 555 1212" for these functions has been clearly established
by experiments with multicast audio and video applications a
number in the
Internet. Example uses United States.

6.5.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 translators and mixers given in Section 2.3
stem from site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Depending on the presence of firewalls and low bandwidth connections,
both application, different degrees of which detail are likely to remain.

7.1 General Description

An RTP translator/mixer connects two or more transport-level
"clouds". Typically, each cloud is defined by a common network and
transport protocol (e.g., IP/UDP) plus a multicast address and
transport level destination port or a pair of unicast addresses and
ports. (Network-level protocol translators, such as IP version 4 to
IP version 6, may be present within a cloud invisibly to RTP.) One
system may serve as a translator or mixer
appropriate for this item. For conference applications, a number of RTP
sessions, but each is considered a logically separate entity.

In order to avoid creating a loop when a translator or mixer is
installed, the following rules must string like
"Murray Hill, New Jersey" may be observed:

o Each 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 clouds connected by translators implementation
and/or user, but format and mixers
participating in one RTP session either must content may be distinct from
all prescribed by a profile.
The LOC value is expected to remain constant for the others in at least one duration of these parameters (protocol,
address, port), a
session, except for mobile hosts.

6.5.6 TOOL: Application or must be isolated at the network level from
the others.

o A derivative 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 first rule is that there must not be
multiple translators or mixers connected in parallel unless by
some arrangement they partition the set name and possibly version of sources to be
forwarded.

Similarly, all RTP end systems that can communicate through one or
more RTP translators or mixers share the same SSRC space, that is,
the SSRC identifiers must be unique among all these end systems.
Section 8.2 describes the collision resolution algorithm by which
SSRC identifiers are kept unique and loops are detected.

Schulzrinne/Casner/Frederick/Jacobson [Page 50]

Internet Draft RTP December 5, 1997

There application
generating the stream, e.g., "videotool 1.2". This information may be many varieties of translators and mixers designed
useful for
different debugging purposes and applications. Some examples are is similar to add or
remove encryption, change the encoding of the data or the underlying
protocols, or replicate between a multicast address and one Mailer or more
unicast addresses. Mail-
System-Version SMTP headers. The distinction between translators and mixers TOOL value is
that a translator passes through the data streams from different
sources separately, whereas a mixer combines them expected to form one new
stream:

Translator: Forwards RTP packets with their SSRC identifier intact;
this makes it possible remain
constant for receivers to identify individual
sources even though packets from all the sources pass through
the same translator and carry the translator's network source
address. Some kinds of translators will pass through the data
untouched, but others may change the encoding duration of the data and
thus the session.

6.5.7 NOTE: Notice/status SDES item

Schulzrinne/Casner/Frederick/Jacobson [Page 46]

Internet Draft RTP data payload type and timestamp. If multiple data
packets are re-encoded into one, or vice versa, a translator
must assign new sequence numbers to the outgoing packets. Losses
in the incoming packet stream may induce corresponding gaps in
the outgoing sequence numbers. Receivers cannot detect the
presence of a translator unless they know by some other means
what payload type or transport address was used by August 7, 1998

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 original
source.

Mixer: Receives streams of RTP data packets from one source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following semantics are suggested for this item, but these or more sources,
possibly changes the data format, combines the streams in some
manner and then forwards the combined stream. Since the timing
among multiple input sources will not generally
other semantics may be synchronized,
the mixer will make timing adjustments among the streams and
generate its own timing explicitly defined by a profile. The NOTE item
is intended for transient messages describing the combined stream, so it is current state of
the
synchronization source. Thus, all data packets forwarded by source, e.g., "on the phone, can't talk". Or, during a
mixer will seminar,
this item might be marked with the mixer's own SSRC identifier. In
order used to preserve convey the identity title of the original sources
contributing talk. It should be
used only to the mixed packet, the mixer carry exceptional information and should insert their
SSRC identifiers into not be included
routinely by all participants because this would slow down the CSRC identifier list following rate
at which reception reports and CNAME are sent, thus impairing the
fixed RTP header
performance of the packet. A mixer that is also itself a
contributing source for some packet should explicitly include
its own SSRC identifier in the CSRC list for that packet.

For some applications, protocol. In particular, it may be acceptable for a mixer not to
identify sources in the CSRC list. However, this introduces the
danger that loops involving those sources could should not be detected.

The advantage of included
as an item in a mixer over user's configuration file nor automatically generated
as in a translator for applications like
audio is that the output bandwidth is limited to that of one source
even when multiple sources are active on quote-of-the-day.

Since the input side. This NOTE item may be important for low-bandwidth links. The disadvantage to display while it is that receivers
on active,
the output side don't have any control over rate at which sources other non-CNAME items such as NAME are

Schulzrinne/Casner/Frederick/Jacobson [Page 51]

Internet Draft RTP December 5, 1997

passed through or muted, unless some mechanism is implemented for
remote control transmitted
might be reduced so that the NOTE item can take that part of the mixer. The regeneration 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 synchronization
information by mixers also means that length zero to signal the receivers.
However, receivers can't do inter-media
synchronization should also consider the NOTE item inactive if it
is not received for a small multiple of the original streams. A multi-media mixer could do
it.

6.5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
[E2] [E4] M3:89 (64,45) PRIV=8 | length | legend:
[E3] --------->(M2)----------->(M3)------------| [End system]
E3:64 M2:12 (64) ^ (Mixer) prefix length | E5:45 <Translator> prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
[E5] source: SSRC (CSRCs)
------------------->

Figure 3: Sample RTP network with end systems, mixers and translators

A collection of mixers and translators value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This item is shown in Figure 3 used to
illustrate their effect on SSRC and CSRC identifiers. In the figure,
end systems are shown as rectangles (named E), translators as
triangles (named T) and mixers as ovals (named M). define experimental or application-specific SDES
extensions. The notation "M1:
48(1,17)" designates item contains a packet originating prefix consisting of a mixer M1, identified with
M1's (random) SSRC length-string
pair, followed by the value of 48 and two CSRC identifiers, 1 and 17,
copied from string filling the SSRC identifiers remainder of packets from E1 and E2.

7.2 RTCP Processing in Translators

In addition to forwarding data packets, perhaps modified, translators
and mixers must also process RTCP packets. In many cases, they will
take apart the compound RTCP packets received from end systems to
aggregate SDES information item
and to modify carrying the SR or RR packets.
Retransmission of this information may be triggered desired information. The prefix length field is 8
bits long. The prefix string is a name chosen by the packet
arrival or by person defining
the RTCP interval timer of PRIV item to be unique with respect to other PRIV items this
application might receive. The application creator might choose to
use the translator or mixer
itself. application name plus an additional subtype identification if

Schulzrinne/Casner/Frederick/Jacobson [Page 52] 47]

Internet Draft RTP December 5, 1997

A translator August 7, 1998

needed. Alternatively, it is recommended that does not modify others choose a name
based on the data packets, for example one entity they represent, then coordinate the use of the
name within that just replicates between a multicast address and a unicast
address, may simply forward RTCP packets unmodified as well. A
translator entity.

Note that transforms the payload in prefix consumes some way must make
corresponding transformations in the SR and RR information so that it
still reflects space within the characteristics item's total
length of 255 octets, so the data prefix should be kept as short as
possible. This facility and the reception
quality. These translators must not simply forward constrained RTCP packets. In
general, a translator bandwidth should not aggregate SR
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 RR packets from
different sources into one increases transmission
efficiency.

6.6 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 since indicates that would reduce the
accuracy of the propagation delay measurements based on one or more sources are no longer
active.

version (V), padding (P), length:
As described for the LSR and
DLSR fields. SR sender information: A translator does not generate its own sender
information, but forwards packet (see Section 6.4.1).

packet type (PT): 8 bits
Contains the SR packets received from one cloud constant 203 to the others. identify this as an RTCP BYE
packet.

source count (SC): 5 bits
The SSRC number of SSRC/CSRC identifiers included in this BYE packet.
A count value of zero is left intact valid, but the sender
information must useless.

The rules for when a BYE packet should be modified if required by the translation. sent are specified in
Section 6.3.7.

Schulzrinne/Casner/Frederick/Jacobson [Page 48]

Internet Draft RTP August 7, 1998

If a translator changes BYE packet is received by a mixer, the data encoding, it must change mixer forwards the
"sender's byte count" field. BYE
packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts
down, it also combines several data
packets into one output packet, it must change the "sender's should send a BYE packet count" field. If listing all contributing sources it changes
handles, as well as its own SSRC identifier. Optionally, the timestamp frequency, it
must change 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 timestamp" field in loop detected". The string has the SR packet.

SR/RR reception report blocks: A translator forwards reception
reports received from one cloud to same encoding as that
described for SDES. If the others. Note that these
flow in string fills the direction opposite packet to the data. The SSRC next 32-bit
boundary, the string is left
intact. not null terminated. If a translator combines several data packets into one
output packet, and therefore changes the sequence numbers, it
must make the inverse manipulation for not, the BYE packet loss fields
and
is padded with null octets to the "extended last sequence number" field. next 32-bit boundary. This may be
complex. In the extreme case, there may be no meaningful way to
translate padding
is separate from that indicated by the reception reports, so P bit in the translator may pass on
no reception report at all or a synthetic report based on its
own reception. RTCP header.

6.7 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 general rule APP packet is to do what makes sense for a
particular translation.

A translator does not require an SSRC identifier of its own, but may
choose to allocate one intended for the purpose of sending reports about what 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 has received. These would is recommended that
each APP packet be sent to all redefined without the connected clouds,
each corresponding to subtype and name fields and
registered with the translation of Internet Assigned Numbers Authority using an RTCP
packet type.

version (V), padding (P), length:
As described for the data stream SR packet (see Section 6.4.1).

subtype: 5 bits
May be used as sent a subtype to
that cloud, since reception reports are normally multicast allow a set of APP packets to all
participants.

SDES: Translators typically forward without change the SDES
information they receive from be
defined under one cloud to the others, but may, unique name, or for example, decide to filter non-CNAME SDES information if
bandwidth is limited. The CNAMEs must be forwarded to allow SSRC
identifier collision detection any application-dependent
data.

packet type (PT): 8 bits
Contains the constant 204 to work. A translator that
generates its own RR packets must send SDES CNAME information identify this as an RTCP APP
packet.

name: 4 octets

Schulzrinne/Casner/Frederick/Jacobson [Page 53] 49]

Internet Draft RTP December 5, 1997

about itself to the same clouds that it sends those RR packets.

BYE: Translators forward BYE packets unchanged. August 7, 1998

A translator that is
about to cease forwarding packets should send a BYE packet to
each connected cloud containing all name chosen by the SSRC identifiers that
were previously being forwarded to that cloud, including person defining the
translator's own SSRC identifier if it sent reports set of its own.

APP: Translators forward APP packets unchanged.

7.3 RTCP Processing in Mixers

Since a mixer generates a new data stream of its own, it does not
pass through SR or RR to
be unique with respect to other APP packets at all this application
might receive. The application creator might choose to use the
application name, and instead generates then coordinate the allocation of subtype
values to others who want to define new
information packet types for both sides.

SR sender information: A mixer does not pass through sender
information from the sources
application. Alternatively, it mixes because is recommended that others
choose a name based on the
characteristics of entity they represent, then
coordinate the source streams are lost in use of the mix. As name within that entity. The name is
interpreted as a
synchronization source, the mixer generates its own SR packets sequence of four ASCII characters, with sender information about the mixed data stream
uppercase and sends
them lowercase characters treated as distinct.

application-dependent data: variable length
Application-dependent data may or may not appear in an APP
packet. It is interpreted by the same direction application and not RTP itself.
It must be a multiple of 32 bits long.

7 RTP Translators and Mixers

In addition to end systems, RTP supports the notion of "translators"
and "mixers", which could be considered as "intermediate systems" at
the mixed stream.

SR/RR reception report blocks: A mixer generates its own reception
reports RTP level. Although this support adds some complexity to the
protocol, the need for sources these functions has been clearly established
by experiments with multicast audio and video applications in the
Internet. Example uses of translators and mixers given in Section 2.3
stem from the presence of firewalls and low bandwidth connections,
both of which are likely to remain.

7.1 General Description

An RTP translator/mixer connects two or more transport-level
"clouds". Typically, each cloud is defined by a common network and sends them out only to the
same cloud. It does not send these reception reports to the
other clouds
transport protocol (e.g., IP/UDP) plus a multicast address and does not forward reception reports from one
cloud
transport level destination port or a pair of unicast addresses and
ports. (Network-level protocol translators, such as IP version 4 to the others because the sources would not
IP version 6, may be SSRCs there
(only CSRCs).

SDES: Mixers typically forward without change the SDES information
they receive from one present within a cloud invisibly to the others, but may, RTP.) One
system may serve as a translator or mixer for example,
decide to filter non-CNAME SDES information if bandwidth a number of RTP
sessions, but each is
limited. The CNAMEs must be forwarded to allow SSRC identifier
collision detection considered a logically separate entity.

In order to work. (An identifier in avoid creating a CSRC list
generated by loop when a translator or mixer might collide with an SSRC identifier
generated by an end system.) A mixer is
installed, the following rules must send SDES CNAME
information about itself to be observed:

o Each of the same clouds that it sends SR or
RR packets.

Since connected by translators and mixers do not forward SR or RR packets, they will typically
participating in one RTP session either must be
extracting SDES packets from a compound RTCP packet. To minimize
overhead, chunks distinct from
all the SDES packets may be aggregated into a
single SDES packet which is then stacked on an SR others in at least one of these parameters (protocol,
address, port), or RR packet
originating must be isolated at the network level from
the mixer. The RTCP packet rate may be different on
each side others.

o A derivative of the mixer.

A mixer first rule is that does there must not insert CSRC identifiers may also refrain from be

Schulzrinne/Casner/Frederick/Jacobson [Page 54] 50]

Internet Draft RTP December 5, 1997

forwarding SDES CNAMEs. In this case, the SSRC identifier spaces August 7, 1998

multiple translators or mixers connected in parallel unless by
some arrangement they partition the two clouds are independent. As mentioned earlier, this mode set of
operation creates a danger sources to be
forwarded.

Similarly, all RTP end systems that loops can't can communicate through one or
more RTP translators or mixers share the same SSRC space, that is,
the SSRC identifiers must be unique among all these end systems.
Section 8.2 describes the collision resolution algorithm by which
SSRC identifiers are kept unique and loops are detected.

BYE: Mixers need

There may be many varieties of translators and mixers designed for
different purposes and applications. Some examples are to forward BYE packets. A mixer that add or
remove encryption, change the encoding of the data or the underlying
protocols, or replicate between a multicast address and one or more
unicast addresses. The distinction between translators and mixers is about
that a translator passes through the data streams from different
sources separately, whereas a mixer combines them to
cease forwarding form one new
stream:

Translator: Forwards RTP packets should send a BYE packet with their SSRC identifier intact;
this makes it possible for receivers to each
connected cloud containing identify individual
sources even though packets from all the SSRC identifiers that were
previously being forwarded to that cloud, including sources pass through
the mixer's
own SSRC identifier if it sent reports of its own.

APP: The treatment same translator and carry the translator's network source
address. Some kinds of APP packets by mixers is application-specific.

7.4 Cascaded Mixers

An RTP session translators will pass through the data
untouched, but others may involve a collection change the encoding of mixers the data and translators as
shown in Figure 3.
thus the RTP data payload type and timestamp. If two mixers multiple data
packets are cascaded, such as M2 and M3 re-encoded into one, or vice versa, a translator
must assign new sequence numbers to the outgoing packets. Losses
in the figure, packets received by a mixer may already have been mixed
and incoming packet stream may include a CSRC list with multiple identifiers. The second
mixer should build the CSRC list for induce corresponding gaps in
the outgoing packet using sequence numbers. Receivers cannot detect the
CSRC identifiers from already-mixed input
presence of a translator unless they know by some other means
what payload type or transport address was used by the original
source.

Mixer: Receives streams of RTP data packets from one or more sources,
possibly changes the data format, combines the streams in some
manner and then forwards the SSRC
identifiers from unmixed combined stream. Since the timing
among multiple input packets. This sources will not generally be synchronized,
the mixer will make timing adjustments among the streams and
generate its own timing for the combined stream, so it is shown in the output
arc from
synchronization source. Thus, all data packets forwarded by a
mixer M3 labeled M3:89(64,45) in will be marked with the figure. As in mixer's own SSRC identifier. In
order to preserve the case identity of mixers that are not cascaded, if the resulting CSRC list has more
than 15 identifiers, original sources
contributing to the remainder cannot be included.

8 SSRC Identifier Allocation and Use

The mixed packet, the mixer should insert their
SSRC identifiers into the CSRC identifier carried in list following the
fixed RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be
globally unique within an RTP session. It is crucial that the number
be chosen with care in order packet. A mixer that participants on the same network or
starting at the same time are not likely to choose the same number.

It is not sufficient to use the local network address (such as an
IPv4 address) also itself a
contributing source for the some packet should explicitly include
its own SSRC identifier because in the address CSRC list for that packet.

Schulzrinne/Casner/Frederick/Jacobson [Page 51]

Internet Draft RTP August 7, 1998

For some applications, it may not be
unique. Since RTP translators and mixers enable interoperation among
multiple networks with different address spaces, the allocation
patterns acceptable for addresses within two spaces might result in a much
higher rate of collision than would occur with random allocation.

Multiple sources running on one host would also conflict.

It is also mixer not sufficient to obtain an SSRC identifier simply by
calling random() without carefully initializing
identify sources in the state. An example CSRC list. However, this introduces the
danger that loops involving those sources could not be detected.

The advantage of how to generate a random identifier mixer over a translator for applications like
audio is presented in Appendix A.6.

8.1 Probability of Collision

Schulzrinne/Casner/Frederick/Jacobson [Page 55]

Internet Draft RTP December 5, 1997

Since that the identifiers are chosen randomly, it output bandwidth is possible limited to that two or
more of one source
even when multiple sources will choose are active on the same number. Collision occurs with input side. This may be
important for low-bandwidth links. The disadvantage is that receivers
on the
highest probability when all output side don't have any control over which sources are started simultaneously,
passed through or muted, unless some mechanism is implemented for
example when triggered automatically
remote control of the mixer. The regeneration of synchronization
information by some session management
event. If N mixers also means that receivers can't do inter-media
synchronization of the original streams. A multi-media mixer could do
it.

[E1] [E6]
| |
E1:17 | E6:15 |
| | E6:15
V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17)
(M1)-------------><T1>-----------------><T2>-------------->[E7]
^ ^ E4:47 ^ E4:47
E2:1 | E4:47 | | M3:89 (64,45)
| | |
[E2] [E4] M3:89 (64,45) |
| legend:
[E3] --------->(M2)----------->(M3)------------| [End system]
E3:64 M2:12 (64) ^ (Mixer)
| E5:45 <Translator>
|
[E5] source: SSRC (CSRCs)
------------------->

Figure 3: Sample RTP network with end systems, mixers and translators

A collection of mixers and translators is shown in Figure 3 to
illustrate their effect on SSRC and CSRC identifiers. In the number figure,
end systems are shown as rectangles (named E), translators as
triangles (named T) and mixers as ovals (named M). The notation "M1:
48(1,17)" designates a packet originating a mixer M1, identified with
M1's (random) SSRC value of sources 48 and L the length of the
identifier (here, 32 bits), the probability that two sources
independently pick the same value can be approximated for large N
[20] as CSRC identifiers, 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is
roughly 10**-4.

The typical collision probability is much lower than and 17,
copied from the worst-case
above. When one new source joins an SSRC identifiers of packets from E1 and E2.

Schulzrinne/Casner/Frederick/Jacobson [Page 52]

Internet Draft RTP session August 7, 1998

7.2 RTCP Processing in which all Translators

In addition to forwarding data packets, perhaps modified, translators
and mixers must also process RTCP packets. In many cases, they will
take apart the
other sources already have unique identifiers, compound RTCP packets received from end systems to
aggregate SDES information and to modify the probability SR or RR packets.
Retransmission of
collision is just this information may be triggered by the fraction of numbers used out packet
arrival or by the RTCP interval timer of the space.
Again, if N is translator or mixer
itself.

A translator that does not modify the number of sources data packets, for example one
that just replicates between a multicast address and L the length of a unicast
address, may simply forward RTCP packets unmodified as well. A
translator that transforms the
identifier, payload in some way must make
corresponding transformations in the probability of collision is N / 2**L. For N=1000, SR and RR information so that it
still reflects the
probability is roughly 2*10**-7.

The probability of collision is further reduced by characteristics of the opportunity
for data and the reception
quality. These translators must not simply forward RTCP packets. In
general, a new source to receive translator should not aggregate SR and RR packets from other participants before
sending its first
different sources into one packet (either data or control). If since that would reduce the new source
keeps track
accuracy of the other participants (by SSRC identifier), then
before transmitting its first packet propagation delay measurements based on the new source can verify that
its identifier LSR and
DLSR fields.

SR sender information: A translator does not conflict with any that have been received, or
else choose again.

8.2 Collision Resolution and Loop Detection

Although generate its own sender
information, but forwards the probability of SR packets received from one cloud
to the others. The SSRC identifier collision is low, all RTP
implementations left intact but the sender
information must be prepared to detect collisions and take modified if required by the
appropriate actions to resolve them. translation. If
a source discovers at any
time that another source is using translator changes the same SSRC identifier as its
own, data encoding, it must send an RTCP BYE change the
"sender's byte count" field. If it also combines several data
packets into one output packet, it must change the "sender's
packet for count" field. If it changes the old identifier and
choose another random one. (As explained below, this step timestamp frequency, it
must change the "RTP timestamp" field in the SR packet.

SR/RR reception report blocks: A translator forwards reception
reports received from one cloud to the others. Note that these
flow in the direction opposite to the data. The SSRC is taken
only once in case of a loop.) left
intact. If a receiver discovers that two other
sources are colliding, it may keep the translator combines several data packets from into one
output packet, and discard therefore changes the packets from sequence numbers, it
must make the other when this can be detected by different
source transport addresses or CNAMEs. The two sources are expected to
resolve inverse manipulation for the collision so that packet loss fields
and the situation doesn't last.

Because "extended last sequence number" field. This may be
complex. In the random SSRC identifiers are kept globally unique for each
RTP session, they can also extreme case, there may be used no meaningful way to detect loops that
translate the reception reports, so the translator may be
introduced by mixers or translators. A loop causes duplication of
data and control information, either unmodified pass on
no reception report at all or possibly mixed, as
in the following examples:

o a synthetic report based on its
own reception. The general rule is to do what makes sense for a
particular translation.

A translator does not require an SSRC identifier of its own, but may incorrectly forward a packet
choose to allocate one for the same
multicast group from which purpose of sending reports about what
it has received received. These would be sent to all the packet, either connected clouds,

Schulzrinne/Casner/Frederick/Jacobson [Page 56] 53]

Internet Draft RTP December 5, 1997

directly or through a chain of translators. In that case, August 7, 1998

each corresponding to the
same packet appears several times, originating from different
network sources.

o Two translators incorrectly set up in parallel, i.e., with translation of the
same data stream as sent to
that cloud, since reception reports are normally multicast groups on both sides, would both to all
participants.

SDES: Translators typically forward packets without change the SDES
information they receive from one multicast group cloud to the other. Unidirectional
translators would produce two copies; bidirectional translators
would form a loop.

o others, but may,
for example, decide to filter non-CNAME SDES information if
bandwidth is limited. The CNAMEs must be forwarded to allow SSRC
identifier collision detection to work. A mixer can close a loop by sending translator that
generates its own RR packets must send SDES CNAME information
about itself to the same transport
destination upon which clouds that it receives packets, either directly or
through another mixer or translator. In this case a source
might show up both as an SSRC on sends those RR packets.

BYE: Translators forward BYE packets unchanged. A translator that is
about to cease forwarding packets should send a data BYE packet and a CSRC to
each connected cloud containing all the SSRC identifiers that
were previously being forwarded to that cloud, including the
translator's own SSRC identifier if it sent reports of its own.

APP: Translators forward APP packets unchanged.

7.3 RTCP Processing in Mixers

Since a
mixed mixer generates a new data packet.

A source may discover that stream of its own packets are being looped, own, it does not
pass through SR or that RR packets from another source are being looped (a third-party loop).

Both loops at all and collisions in instead generates new
information for both sides.

SR sender information: A mixer does not pass through sender
information from the random selection sources it mixes because the
characteristics of a the source
identifier result streams are lost in packets arriving with the same SSRC identifier
but mix. As a different source transport address, which may be that of the
end system originating
synchronization source, the packet or an intermediate system.
Therefore, if a source changes mixer generates its source transport address, it must
also choose a new SSRC identifier to avoid being interpreted as a
looped source. Note that if a translator restarts own SR packets
with sender information about the mixed data stream and consequently
changes sends
them in the source transport address (e.g., changes same direction as the UDP source
port number) on which it forwards packets, then all those packets
will appear to receivers mixed stream.

SR/RR reception report blocks: A mixer generates its own reception
reports for sources in each cloud and sends them out only to be looped because the SSRC identifiers
are applied by
same cloud. It does not send these reception reports to the original source
other clouds and will does not change. This problem
may be avoided by keeping the source transport addressed fixed across
restarts, but in any case will be resolved after a timeout at forward reception reports from one
cloud to the
receivers.

Loops or collisions occurring on others because the far side of a translator or
mixer cannot sources would not be detected using the source transport address if all
copies of the packets go through SSRCs there
(only CSRCs).

SDES: Mixers typically forward without change the translator or mixer, however
collisions may still be detected when chunks from two RTCP SDES
packets contain information
they receive from one cloud to the same SSRC identifier others, but different CNAMEs.

To detect and resolve these conflicts, an RTP implementation may, for example,
decide to filter non-CNAME SDES information if bandwidth is
limited. The CNAMEs must
include an algorithm similar be forwarded to the one described below. It ignores
packets from allow SSRC identifier
collision detection to work. (An identifier in a new source or loop that CSRC list
generated by a mixer might collide with an established
source. It resolves collisions with the participant's own SSRC identifier
generated by sending an RTCP BYE for the old identifier and choosing
a new one. However, when the collision was induced by a loop of the
participant's own packets, the algorithm will choose a new identifier
only once and thereafter ignore packets from end system.) A mixer must send SDES CNAME
information about itself to the looping source same clouds that it sends SR or

Schulzrinne/Casner/Frederick/Jacobson [Page 57] 54]

Internet Draft RTP December 5, 1997

transport address. This is required to avoid a flood of BYE August 7, 1998

RR packets.

This algorithm requires keeping a table indexed by the source
identifier and containing the source transport addresses

Since mixers do not forward SR or RR packets, they will typically be
extracting SDES packets from the
first RTP packet and first a compound RTCP packet received with that identifier,
along with other state for that source. Two source transport
addresses are required since, for example, packet. To minimize
overhead, chunks from the UDP source port
numbers SDES packets may be different aggregated into a
single SDES packet which is then stacked on RTP and RTCP packets. However, it an SR or RR packet
originating from the mixer. The RTCP packet rate may be
assumed that different on
each side of the network address is mixer.

A mixer that does not insert CSRC identifiers may also refrain from
forwarding SDES CNAMEs. In this case, the same in both source transport
addresses.

Each SSRC or CSRC identifier received in an RTP or RTCP packet is
looked up spaces in
the source identifier table in order two clouds are independent. As mentioned earlier, this mode of
operation creates a danger that loops can't be detected.

BYE: Mixers need to process forward BYE packets. A mixer that
data or control information. The source transport address from the
packet is compared to the corresponding source transport address in
the table about to detect
cease forwarding packets should send a loop or collision if they don't match. For
control packets, BYE packet to each element with its own SSRC id, for example an
SDES chunk, requires a separate lookup. (The SSRC id in a reception
report block is an exception because it identifies a source heard by
connected cloud containing all the reporter, and that SSRC id is unrelated identifiers that were
previously being forwarded to that cloud, including the source transport
adddress of the RTCP packet mixer's
own SSRC identifier if it sent reports of its own.

APP: The treatment of APP packets by the reporter.) If the SSRC or
CSRC mixers is not found, application-specific.

7.4 Cascaded Mixers

An RTP session may involve a new entry is created. These table entries collection of mixers and translators as
shown in Figure 3. If two mixers are
removed when an RTCP BYE packet is received with the corresponding
SSRC id cascaded, such as M2 and validated M3 in
the figure, packets received by a matching source transport address, or
after no packets mixer may already have arrived for been mixed
and may include a relatively long time (see Section
6.3).

Note that if two sources on the same host are transmitting CSRC list with multiple identifiers. The second
mixer should build the
same source identifier at the time a receiver begins operation, it
would be possible that CSRC list for the first RTP outgoing packet received came using the
CSRC identifiers from one of already-mixed input packets and the sources while SSRC
identifiers from unmixed input packets. This is shown in the first RTCP packet received came output
arc from mixer M3 labeled M3:89(64,45) in the other.
This would cause figure. As in the wrong RTCP information to case
of mixers that are not cascaded, if the resulting CSRC list has more
than 15 identifiers, the remainder cannot be associated with included.

8 SSRC Identifier Allocation and Use

The SSRC identifier carried in the RTP data, but this situation should be sufficiently rare header and harmless
that it may be disregarded.

In order to track loops in various fields
of the participant's own data packets, it RTCP packets is
also necessary to keep a separate list of source transport addresses
(not identifiers) random 32-bit number that have been found is required to be conflicting. As in
globally unique within an RTP session. It is crucial that the
source identifier table, two source transport addresses must number
be kept chosen with care in order that participants on the same network or
starting at the same time are not likely to choose the same number.

It is not sufficient to separately track conflicting RTP and RTCP packets. Note that use the
conflicting local network address list should be a short, usually empty. Each
element in this list stores the source addresses plus (such as an
IPv4 address) for the time when identifier because the most recent conflicting packet was received. An element address may not be
removed from
unique. Since RTP translators and mixers enable interoperation among
multiple networks with different address spaces, the list when no conflicting packet has arrived from
that source allocation
patterns for addresses within two spaces might result in a time much

Schulzrinne/Casner/Frederick/Jacobson [Page 55]

Internet Draft RTP August 7, 1998

higher rate of collision than would occur with random allocation.

Multiple sources running on one host would also conflict.

It is also not sufficient to obtain an SSRC identifier simply by
calling random() without carefully initializing the order state. An example
of 10 RTCP report intervals (see
Section 6.2).

For how to generate a random identifier is presented in Appendix A.6.

8.1 Probability of Collision

Since the algorithm as shown, identifiers are chosen randomly, it is assumed possible that two or
more sources will choose the participant's own

Schulzrinne/Casner/Frederick/Jacobson [Page 58]

Internet Draft RTP December 5, 1997

source identifier and state same number. Collision occurs with the
highest probability when all sources are included in started simultaneously, for
example when triggered automatically by some session management
event. If N is the number of sources and L the length of the source
identifier
table. The algorithm could be restructured to first make a separate
comparison against (here, 32 bits), the participant's own source identifier.

IF probability that two sources
independently pick the same value can be approximated for large N
[20] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the SSRC or CSRC identifier probability is not found in
roughly 10**-4.

The typical collision probability is much lower than the source
identifier table:
THEN create a worst-case
above. When one new entry storing the data or control source
transport address, joins an RTP session in which all the SSRC or CSRC id and
other state.
CONTINUE with normal processing.

(identifier sources already have unique identifiers, the probability of
collision is found in just the table)

IF fraction of numbers used out of the table entry was created on receipt space.
Again, if N is the number of a control packet sources and this L the length of the
identifier, the probability of collision is N / 2**L. For N=1000, the first data packet or vice versa:
THEN store
probability is roughly 2*10**-7.

The probability of collision is further reduced by the opportunity
for a new source transport address to receive packets from this packet.
CONTINUE with normal processing.
IF other participants before
sending its first packet (either data or control). If the new source transport address from
keeps track of the other participants (by SSRC identifier), then
before transmitting its first packet matches
the one saved in the table entry for this identifier:
THEN CONTINUE new source can verify that
its identifier does not conflict with normal processing.

(an any that have been received, or
else choose again.

8.2 Collision Resolution and Loop Detection

Although the probability of SSRC identifier collision or a loop is indicated)

IF low, all RTP
implementations must be prepared to detect collisions and take the
appropriate actions to resolve them. If a source discovers at any
time that another source identifier is not the participant's own:
THEN IF using the source same SSRC identifier is from as its
own, it must send an RTCP SDES chunk
containing a CNAME item that differs from BYE packet for the CNAME old identifier and
choose another random one. (As explained below, this step is taken
only once in the table entry:
THEN (optionally) count case of a third-party collision.
ELSE (optionally) count loop.) If a third-party loop.
ABORT processing of data packet or control element.

(a collision or loop of receiver discovers that two other
sources are colliding, it may keep the participant's own packets)

IF packets from one and discard
the source transport address is found in packets from the list of
conflicting data or control other when this can be detected by different
source transport addresses:
THEN IF addresses or CNAMEs. The two sources are expected to

Schulzrinne/Casner/Frederick/Jacobson [Page 56]

Internet Draft RTP August 7, 1998

resolve the source identifier is not from an RTCP SDES chunk
containing a CNAME item OR if collision so that CNAME is the
participant's own:
THEN (optionally) count occurrence of own traffic looped.
mark current time in conflicting address list entry.
ABORT processing situation doesn't last.

Because the random SSRC identifiers are kept globally unique for each
RTP session, they can also be used to detect loops that may be
introduced by mixers or translators. A loop causes duplication of
data and control information, either unmodified or possibly mixed, as
in the following examples:

o A translator may incorrectly forward a packet to the same
multicast group from which it has received the packet, either
directly or control element.
log occurrence of a collision.
create through a new entry in chain of translators. In that case, the conflicting data or control source
transport address list and mark current time.
send an RTCP BYE
same packet appears several times, originating from different
network sources.

o Two translators incorrectly set up in parallel, i.e., with the old SSRC identifier.
choose
same multicast groups on both sides, would both forward packets
from one multicast group to the other. Unidirectional
translators would produce two copies; bidirectional translators
would form a new identifier.
create loop.

o A mixer can close a new entry in the source identifier table with the
old SSRC plus loop by sending to the source same transport address from the data

Schulzrinne/Casner/Frederick/Jacobson [Page 59]

Internet Draft RTP December 5, 1997
destination upon which it receives packets, either directly or control packet being processed.
CONTINUE with normal processing.
through another mixer or translator. In this algorithm, packets from case a newly conflicting source address
will be ignored and packets from the original source will be kept.
(If the original source was through
might show up both as an SSRC on a mixer data packet and later the same a CSRC in a
mixed data packet.

A source
is received directly, the receiver may be well advised to switch
unless other sources in the mix would be lost.) If no discover that its own packets are being looped, or that
packets arrive from the original source for an extended period, the table entry will
be timed out and the new source will be able to take over. This might
occur if the original another source detects the collision are being looped (a third-party loop).

Both loops and moves to collisions in the random selection of a new source identifier, but
identifier result in packets arriving with the usual case an RTCP BYE packet will same SSRC identifier
but a different source transport address, which may be
received from that of the original source to delete
end system originating the state without having
to wait for packet or an intermediate system.
Therefore, if a timeout.

When source changes its source transport address, it must
also choose a new SSRC identifier is chosen due to avoid being interpreted as a collision, the
candidate identifier should first be looked up in the source
identifier table to see if it was already in use by some other
looped source. If so, another candidate should be generated and the process
repeated.

A loop of data packets to Note that if a multicast destination can cause severe
network flooding. All mixers translator restarts and translators are required to
implement a loop detection algorithm like the one here so that they
can break loops. This should limit consequently
changes the excess traffic to no more than
one duplicate copy of source transport address (e.g., changes the original traffic, UDP source
port number) on which may allow the
session it forwards packets, then all those packets
will appear to receivers to continue so that the cause of the loop can be found and
fixed. However, in extreme cases where a mixer or translator does not
properly break looped because the loop and high traffic levels result, it may be
necessary for end systems to cease transmitting data or control
packets entirely. SSRC identifiers
are applied by the original source and will not change. This decision problem
may depend upon the application. An
error condition should be indicated as appropriate. Transmission
might avoided by keeping the source transport addressed fixed across
restarts, but in any case will be attempted again periodically resolved after a long, random time (on timeout at the order of minutes).

8.3 Use with Layered Encodings

For layered encodings transmitted
receivers.

Loops or collisions occurring on separate RTP sessions (see
Section 2.4), the far side of a single SSRC identifier space should translator or
mixer cannot be used across detected using the sessions of source transport address if all layers and
copies of the core (base) layer should packets go through the translator or mixer, however
collisions may still be used
for SSRC identifier allocation and collision resolution. When a
source discovers that it has collided, it transmits an detected when chunks from two RTCP BYE
message on only the base layer but changes the SSRC identifier to the
new value in all layers.

9 Security SDES

Schulzrinne/Casner/Frederick/Jacobson [Page 60] 57]

Internet Draft RTP December 5, 1997

Lower layer protocols may eventually provide all August 7, 1998

packets contain the security
services that may be desired for applications of RTP, including
authentication, integrity, same SSRC identifier but different CNAMEs.

To detect and confidentiality. These services have
recently been specified for IP. Since resolve these conflicts, an RTP implementation must
include an algorithm similar to the need for one described below. It ignores
packets from a confidentiality
service is well established in the initial audio and video
applications new source or loop that are expected to use RTP, a confidentiality service
is defined in the next section for use collide with an established
source. It resolves collisions with RTP and RTCP until lower
layer services are available. The overhead on the protocol participant's own SSRC
identifier by sending an RTCP BYE for this
service is low, so the penalty will be minimal if this service is
obsoleted by lower layer services in old identifier and choosing
a new one. However, when the future.

Alternatively, other services, other implementations collision was induced by a loop of services the
participant's own packets, the algorithm will choose a new identifier
only once and
other algorithms may be defined for RTP in thereafter ignore packets from the future if warranted.
The selection presented here looping source
transport address. This is meant required to simplify implementation avoid a flood of
interoperable, secure applications BYE packets.

This algorithm requires keeping a table indexed by the source
identifier and provide guidance to
implementors. No claim is made that containing the methods presented here source transport addresses from the
first RTP packet and first RTCP packet received with that identifier,
along with other state for that source. Two source transport
addresses are
appropriate required since, for a particular security need. A profile example, the UDP source port
numbers may specify
which services and algorithms should be offered by applications, different on RTP and RTCP packets. However, it may provide guidance as to their appropriate use.

Key distribution and certificates are outside the scope of this
document.

9.1 Confidentiality

Confidentiality means be
assumed that only the intended receiver(s) can decode
the received packets; for others, the packet contains no useful
information. Confidentiality of the content network address is achieved by
encryption.

When encryption of the same in both source transport
addresses.

Each SSRC or CSRC identifier received in an RTP or RTCP packet is desired, all
looked up in the octets that will
be encapsulated for transmission source identifier table in a single lower-layer order to process that
data or control information. The source transport address from the
packet are
encrypted as a unit. For RTCP, a 32-bit random number is prepended compared to the unit before encryption corresponding source transport address in
the table to deter known plaintext attacks. detect a loop or collision if they don't match. For RTP,
no prefix
control packets, each element with its own SSRC id, for example an
SDES chunk, requires a separate lookup. (The SSRC id in a reception
report block is required an exception because it identifies a source heard by
the sequence number reporter, and timestamp
fields are initialized with random offsets.

For RTCP, it that SSRC id is allowed unrelated to split a compound the source transport
adddress of the RTCP packet into two
lower-layer packets, one to be encrypted and one to be sent in by the
clear. For example, SDES information might be encrypted while
reception reports were sent in reporter.) If the clear to accommodate third-party
monitors that are SSRC or
CSRC is not privy to the encryption key. In this example,
depicted in Fig. 4, the SDES information must be appended to found, a new entry is created. These table entries are
removed when an RR RTCP BYE packet is received with no reports (and the encrypted) to satisfy corresponding
SSRC id and validated by a matching source transport address, or
after no packets have arrived for a relatively long time (see Section
6.2.1).

Note that if two sources on the requirement
that all compound RTCP packets begin same host are transmitting with an SR or RR packet.

The presence of encryption and the use of
same source identifier at the correct key are

Schulzrinne/Casner/Frederick/Jacobson [Page 61]

Internet Draft time a receiver begins operation, it
would be possible that the first RTP December 5, 1997

UDP packet UDP received came from one of
the sources while the first RTCP packet
------------------------------------- -------------------------
[32-bit ][ ][ # ] [ # sender # receiver]
[random ][ RR ][SDES # CNAME, ...] [ SR # report # report ]
[integer][(empty)][ # ] [ # # ]
------------------------------------- -------------------------
encrypted not encrypted

#: SSRC

Figure 4: Encrypted and non-encrypted received came from the other.
This would cause the wrong RTCP packets

confirmed by information to be associated with the receiver through header or payload validity checks.
Examples of such validity checks for
RTP data, but this situation should be sufficiently rare and RTCP headers are given
in Appendices A.1 and A.2.

The default encryption algorithm is the Data Encryption Standard
(DES) algorithm in cipher block chaining (CBC) mode, as described in
Section 1.1 of RFC 1423 [21], except harmless
that padding it may be disregarded.

In order to a multiple track loops of 8
octets is indicated as described for the P bit in Section 5.1. The
initialization vector participant's own data packets, it is zero because random values are supplied
also necessary to keep a separate list of source transport addresses
(not identifiers) that have been found to be conflicting. As in the

Schulzrinne/Casner/Frederick/Jacobson [Page 58]

Internet Draft RTP August 7, 1998

source identifier table, two source transport addresses must be kept
to separately track conflicting RTP and RTCP packets. Note that the
conflicting address list should be a short, usually empty. Each
element in this list stores the RTP header or by source addresses plus the random prefix time when
the most recent conflicting packet was received. An element may be
removed from the list when no conflicting packet has arrived from
that source for compound RTCP packets. For
details a time on the use order of CBC initialization vectors, see [22].
Implementations that support encryption should always support 10 RTCP report intervals (see
Section 6.2).

For the DES algorithm in CBC mode as the default to maximize interoperability.
This method is chosen because shown, it has been demonstrated to be easy and
practical to use in experimental audio is assumed that the participant's own
source identifier and video tools state are included in operation
on the Internet. Other encryption algorithms may source identifier
table. The algorithm could be specified
dynamically for a session by non-RTP means.

As an alternative restructured to encryption at first make a separate
comparison against the RTP level as described above,
profiles may define additional payload types for encrypted encodings.
Those encodings must specify how padding participant's own source identifier.

IF the SSRC or CSRC identifier is not found in the source
identifier table:
THEN create a new entry storing the data or control source
transport address, the SSRC or CSRC id and other aspects of state.
CONTINUE with normal processing.

(identifier is found in the
encryption should be handled. This method allows encrypting only table)

IF the table entry was created on receipt of a control packet
and this is the first data while leaving packet or vice versa:
THEN store the headers source transport address from this packet.
CONTINUE with normal processing.
IF the source transport address from the packet matches
the one saved in the clear table entry for applications where
that this identifier:
THEN CONTINUE with normal processing.

(an identifier collision or a loop is indicated)

IF the source identifier is desired. It may be particularly useful for hardware devices
that will handle both decryption and decoding.

9.2 Authentication and Message Integrity

Authentication and message integrity are not defined the participant's own:
THEN IF the source identifier is from an RTCP SDES chunk
containing a CNAME item that differs from the CNAME
in the current
specification table entry:
THEN (optionally) count a third-party collision.
ELSE (optionally) count a third-party loop.
ABORT processing of RTP since these services would data packet or control element.

(a collision or loop of the participant's own packets)

IF the source transport address is found in the list of
conflicting data or control source transport addresses:
THEN IF the source identifier is not be directly
feasible without from an RTCP SDES chunk
containing a key management infrastructure. It is expected CNAME item OR if that
authentication and integrity services will be provided by lower layer CNAME is the
participant's own:

Schulzrinne/Casner/Frederick/Jacobson [Page 62] 59]

Internet Draft RTP December 5, 1997

protocols in the future.

10 RTP over Network and Transport Protocols

This section describes issues specific to carrying RTP packets within
particular network and transport protocols. The following rules apply
unless superseded by protocol-specific definitions outside this
specification.

RTP relies on the underlying protocol(s) to provide demultiplexing of
RTP August 7, 1998

THEN (optionally) count occurrence of own traffic looped.
mark current time in conflicting address list entry.
ABORT processing of data and RTCP packet or control streams. For UDP element.
log occurrence of a collision.
create a new entry in the conflicting data or control source
transport address list and similar protocols, RTP
uses mark current time.
send an even port number and the corresponding RTCP stream uses the
next higher (odd) port number. If an application is supplied BYE packet with an
odd number for use as the RTP port, it should replace this number old SSRC identifier.
choose a new identifier.
create a new entry in the source identifier table with the next lower (even) number.
old SSRC plus the source transport address from the data
or control packet being processed.
CONTINUE with normal processing.

In this algorithm, packets from a unicast session, applications should newly conflicting source address
will be prepared to receive RTP
data and control on one port pair ignored and send to another.

It is recommended that layered encoding applications (see Section
2.4) use a set of contiguous port numbers. Ports must packets from the original source will be distinct
because of a widespread deficiency in existing operating systems that
prevents use of kept.
(If the same port with multiple multicast addresses, original source was through a mixer and
for unicast, there is only one permissible address. Thus for layer n, later the data port same source
is P + 2n, and received directly, the control port is P + 2n + 1. When IP
multicast is used, receiver may be well advised to switch
unless other sources in the addresses must also mix would be distinct because
multicast routing and group membership are managed on lost.) If no packets arrive
from the original source for an address
granularity. However, allocation of contiguous IP multicast addresses
cannot extended period, the table entry will
be assumed because some groups may require different scopes timed out and may therefore the new source will be allocated able to take over. This might
occur if the original source detects the collision and moves to a new
source identifier, but in the usual case an RTCP BYE packet will be
received from different address ranges.

RTP data packets contain no length field or other delineation,
therefore RTP relies on the underlying protocol(s) original source to provide delete the state without having
to wait for a
length indication. The maximum length of RTP packets timeout.

When a new SSRC identifier is limited only
by the underlying protocols.

If RTP packets are chosen due to a collision, the
candidate identifier should first be carried looked up in an underlying protocol that
provides the abstraction of a continuous octet stream rather than
messages (packets), an encapsulation of source
identifier table to see if it was already in use by some other
source. If so, another candidate should be generated and the RTP process
repeated.

A loop of data packets must be
defined to provide a framing mechanism. Framing is also needed if multicast destination can cause severe
network flooding. All mixers and translators are required to
implement a loop detection algorithm like the one here so that they
can break loops. This should limit the excess traffic to no more than
one duplicate copy of the
underlying protocol original traffic, which may contain padding allow the
session to continue so that the extent cause of the RTP
payload cannot loop can be determined. The framing mechanism is found and
fixed. However, in extreme cases where a mixer or translator does not defined
here.

A profile
properly break the loop and high traffic levels result, it may specify a framing method to be used even when RTP is
carried in protocols that do provide framing in order
necessary for end systems to allow
carrying several RTP packets in one lower-layer protocol cease transmitting data unit,
such or control
packets entirely. This decision may depend upon the application. An
error condition should be indicated as appropriate. Transmission
might be attempted again periodically after a UDP packet. Carrying several RTP packets in one network or long, random time (on
the order of minutes).

8.3 Use with Layered Encodings

Schulzrinne/Casner/Frederick/Jacobson [Page 63] 60]

Internet Draft RTP December 5, 1997

transport packet reduces header overhead and may simplify
synchronization between different streams.

11 Summary of Protocol Constants

This section contains August 7, 1998

For layered encodings transmitted on separate RTP sessions (see
Section 2.4), a summary listing single SSRC identifier space should be used across
the sessions of all layers and the constants defined in
this specification.

The RTP payload type (PT) constants are defined core (base) layer should be used
for SSRC identifier allocation and collision resolution. When a
source discovers that it has collided, it transmits an RTCP BYE
message on only the base layer but changes the SSRC identifier to the
new value in profiles rather
than this document. However, all layers.

9 Security

Lower layer protocols may eventually provide all the octet security
services that may be desired for applications of RTP, including
authentication, integrity, and confidentiality. These services have
been specified for IP in [21]. Since the initial audio and video
applications using RTP header which
contains needed a confidentiality service before such
services were available for the marker bit(s) and payload type must avoid IP layer, the reserved
values 200 confidentiality service
described in the next section was defined for use with RTP and 201 (decimal) RTCP.
That description is included here to distinguish codify existing practice. New
applications of RTP packets from MAY implement this RTP-specific confidentiality
service for backward compatibility, and/or they MAY implement IP
layer security services. The overhead on the RTCP
SR and RR packet types RTP protocol for this
confidentiality service is low, so the header validation procedure described penalty will be minimal if
this service is obsoleted by lower layer services in Appendix A.1. For the standard definition future.

Alternatively, other services, other implementations of one marker bit services and a
7-bit payload type field as shown
other algorithms may be defined for RTP in this specification, this
restriction means that payload types 72 the future if warranted.
The selection presented here is meant to simplify implementation of
interoperable, secure applications and 73 provide guidance to
implementors. No claim is made that the methods presented here are reserved.

11.1 RTCP packet types

abbrev. name value
SR sender report 200
RR receiver report 201
SDES source description 202
BYE goodbye 203
APP application-defined 204

These type values were chosen in
appropriate for a particular security need. A profile may specify
which services and algorithms should be offered by applications, and
may provide guidance as to their appropriate use.

Key distribution and certificates are outside the range 200-204 scope of this
document.

9.1 Confidentiality

Confidentiality means that only the intended receiver(s) can decode
the received packets; for improved
header validity checking others, the packet contains no useful
information. Confidentiality of the content is achieved by
encryption.

When encryption of RTCP packets compared to RTP packets or
other unrelated packets. When the RTCP is desired, all the octets that will
be encapsulated for transmission in a single lower-layer packet type field are
encrypted as a unit. For RTCP, a 32-bit random number is compared prepended to
the corresponding octet of the RTP header, this range corresponds unit before encryption to deter known plaintext attacks. For RTP,
no prefix is required because the marker bit being 1 (which sequence number and timestamp

Schulzrinne/Casner/Frederick/Jacobson [Page 61]

Internet Draft RTP August 7, 1998

fields are initialized with random offsets.

For RTCP, it usually is not in data packets) allowed to split a compound RTCP packet into two
lower-layer packets, one to be encrypted and one to be sent in the high bit of the standard payload type field being 1 (since
clear. For example, SDES information might be encrypted while
reception reports were sent in the static payload types clear to accommodate third-party
monitors that are typically defined not privy to the encryption key. In this example,
depicted in Fig. 4, the low half). This
range was also chosen to SDES information must be some distance numerically from 0 and 255
since all-zeros and all-ones are common data patterns.

Since appended to an RR
packet with no reports (and the encrypted) to satisfy the requirement
that all compound RTCP packets must begin with an SR or RR, these codes
were chosen as an even/odd pair to allow the RR packet.

UDP packet UDP packet
------------------------------------- -------------------------
[32-bit ][ ][ # ] [ # sender # receiver]
[random ][ RR ][SDES # CNAME, ...] [ SR # report # report ]
[integer][(empty)][ # ] [ # # ]
------------------------------------- -------------------------
encrypted not encrypted

#: SSRC

Figure 4: Encrypted and non-encrypted RTCP validity check to
test the maximum number packets

The presence of bits with mask encryption and value.

Other constants are assigned by IANA. Experimenters are encouraged to
register the numbers they need for experiments, and then unregister
those which prove to be unneeded.

11.2 SDES types

Schulzrinne/Casner/Frederick/Jacobson [Page 64]

Internet Draft RTP December 5, 1997

abbrev. name value
END end of SDES list 0
CNAME canonical name 1
NAME user name 2
EMAIL user's electronic mail address 3
PHONE user's phone number 4
LOC geographic user location 5
TOOL name use of application or tool 6
NOTE notice about the source 7
PRIV private extensions 8

Other constants correct key are assigned
confirmed by IANA. Experimenters are encouraged to
register the numbers they need receiver through header or payload validity checks.
Examples of such validity checks for experiments, and then unregister
those which prove to be unneeded.

12 RTP Profiles and Payload Format Specifications

A complete specification RTCP headers are given
in Appendices A.1 and A.2.

The default encryption algorithm is the Data Encryption Standard
(DES) algorithm in cipher block chaining (CBC) mode, as described in
Section 1.1 of RTP for RFC 1423 [22], except that padding to a particular application will
require one or more companion documents multiple of two types 8
octets is indicated as described here:
profiles, and payload format specifications.

RTP may be used for a variety of applications with somewhat differing
requirements. the P bit in Section 5.1. The flexibility to adapt to those requirements
initialization vector is
provided by allowing multiple choices zero because random values are supplied in
the main protocol
specification, then selecting the appropriate choices RTP header or defining
extensions by the random prefix for a particular environment and class compound RTCP packets. For
details on the use of applications CBC initialization vectors, see [23].
Implementations that support encryption should always support the DES
algorithm in
a separate profile document. Typically an application will operate
under only one profile so there is no explicit indication of which
profile CBC mode as the default to maximize interoperability.
This method is chosen because it has been demonstrated to be easy and
practical to use in use. A profile for experimental audio and video applications may be
found tools in operation
on the companion RFC 1890 (updated by Internet-Draft draft-
ietf-avt-profile-new ). Profiles are typically titled "RTP Profile
for ...".

The second type of companion document is a payload format
specification, which defines how a particular kind of payload data,
such as H.261 encoded video, should be carried in RTP. These
documents are typically titled "RTP Payload Format for XYZ
Audio/Video Encoding". Payload formats may be useful under multiple
profiles and Internet. Other encryption algorithms may therefore be defined independently of any particular
profile. The profile documents are then responsible for assigning a
default mapping of that format to a payload type value if needed.

Within this specification, the following items have been identified specified
dynamically for possible definition within a profile, but this list is not meant session by non-RTP means.

As an alternative to be exhaustive:

RTP data header: The octet in encryption at the RTP data header that contains IP level or at the RTP level

Schulzrinne/Casner/Frederick/Jacobson [Page 65] 62]

Internet Draft RTP December 5, 1997

marker bit and August 7, 1998

as described above, profiles may define additional payload type field types for
encrypted encodings. Those encodings must specify how padding and
other aspects of the encryption should be handled. This method allows
encrypting only the data while leaving the headers in the clear for
applications where that is desired. It may be redefined by a profile
to suit different requirements, particularly useful for example with more or fewer
marker bits (Section 5.3, p. 14).

Payload types: Assuming
hardware devices that will handle both decryption and decoding.

9.2 Authentication and Message Integrity

Authentication and message integrity services are not defined at the
RTP level since these services would not be directly feasible without
a payload type field key management infrastructure. It is included, the
profile expected that authentication
and integrity services will usually define a set of payload formats (e.g.,
media encodings) be provided by lower layer protocols.

10 RTP over Network and a default static mapping of those formats Transport Protocols

This section describes issues specific to payload type values. Some of the payload formats may be
defined carrying RTP packets within
particular network and transport protocols. The following rules apply
unless superseded by reference protocol-specific definitions outside this
specification.

RTP relies on the underlying protocol(s) to separate payload format specifications. provide demultiplexing of
RTP data and RTCP control streams. For each payload type defined, UDP and similar protocols, RTP
uses an even port number and the profile must specify corresponding RTCP stream uses the
next higher (odd) port number. If an application is supplied with an
odd number for use as the RTP
timestamp clock rate to be used (Section 5.1, p. 13).

RTP data header additions: Additional fields may port, it should replace this number
with the next lower (even) number.

In a unicast session, applications should be appended prepared to the
fixed receive RTP
data header if some additional functionality and control on one port pair and send to another.

It is