range [0.5,1.5] times the calculated interval to avoid
unintended synchronization of all participants [10]. The first
RTCP packet sent after joining a session is also delayed by a
random variation of half the minimum RTCP interval in case the
application is started at multiple sites simultaneously, for
example as initiated by a session announcement.
o A dynamic estimate of the average compound RTCP packet size is
calculated, including all those received and sent, to
automatically adapt to changes in the amount of control
information carried.
This algorithm may be used for sessions in which all participants are
allowed to send. In that case, the session bandwidth parameter is the
product of the individual sender's bandwidth times the number of
participants, and the RTCP bandwidth is 5% of that.
6.2.1 Maintaining the number of session members
Calculation of the RTCP packet interval depends upon an estimate of
the number of sites participating in the session. New sites are added
to the count when they are heard, and an entry for each is created in
a table indexed by the SSRC or CSRC identifier (see Section 8.2) to
keep track of them. New entries may not be considered valid until
multiple packets carrying the new SSRC have been received (see
Appendix A.1). Entries may be deleted from the table when an RTCP BYE
packet with the corresponding SSRC identifier is received.
A participant may mark another site inactive, or delete it if not yet
valid, if no RTP or RTCP packet has been received for a small number
of RTCP report intervals (5 is suggested). This provides some
robustness against packet loss. All sites must calculate roughly the
same value for the RTCP report interval in order for this timeout to
work properly.
Once a site has been validated, then if it is later marked inactive
the state for that site should still be retained and the site should
continue to be counted in the total number of sites sharing RTCP
bandwidth for a period long enough to span typical network
partitions. This is to avoid excessive traffic, when the partition
heals, due to an RTCP report interval that is too small. A timeout of
30 minutes is suggested. Note that this is still larger than 5 times
the largest value to which the RTCP report interval is expected to
usefully scale, about 2 to 5 minutes.
6.2.2 Allocation of source description bandwidth
This specification defines several source description (SDES) items in
addition to the mandatory CNAME item, such as NAME (personal name)
and EMAIL (email address). It also provides a means to define new
application-specific RTCP packet types. Applications should exercise
caution in allocating control bandwidth to this additional
information because it will slow down the rate at which reception
reports and CNAME are sent, thus impairing the performance of the
protocol. It is recommended that no more than 20% of the RTCP
bandwidth allocated to a single participant be used to carry the
additional information. Furthermore, it is not intended that all
SDES items should be included in every application. Those that are
included should be assigned a fraction of the bandwidth according to
their utility. Rather than estimate these fractions dynamically, it
is recommended that the percentages be translated statically into
report interval counts based on the typical length of an item.
For example, an application may be designed to send only CNAME, NAME
and EMAIL and not any others. NAME might be given much higher
priority than EMAIL because the NAME would be displayed continuously
in the application's user interface, whereas EMAIL would be displayed
only when requested. At every RTCP interval, an RR packet and an SDES
packet with the CNAME item would be sent. For a small session
operating at the minimum interval, that would be every 5 seconds on
the average. Every third interval (15 seconds), one extra item would
be included in the SDES packet. Seven out of eight times this would
be the NAME item, and every eighth time (2 minutes) it would be the
EMAIL item.
When multiple applications operate in concert using cross-application
binding through a common CNAME for each participant, for example in a
multimedia conference composed of an RTP session for each medium, the
additional SDES information might be sent in only one RTP session.
The other sessions would carry only the CNAME item.
6.3 Sender and Receiver Reports
RTP receivers provide reception quality feedback using RTCP report
packets which may take one of two forms depending upon whether or not
the receiver is also a sender. The only difference between the sender
report (SR) and receiver report (RR) forms, besides the packet type
code, is that the sender report includes a 20-byte sender information
section for use by active senders. The SR is issued if a site has
sent any data packets during the interval since issuing the last
report or the previous one, otherwise the RR is issued.
Both the SR and RR forms include zero or more reception report
blocks, one for each of the synchronization sources from which this
receiver has received RTP data packets since the last report. Reports
are not issued for contributing sources listed in the CSRC list. Each
reception report block provides statistics about the data received
from the particular source indicated in that block. Since a maximum
of 31 reception report blocks will fit in an SR or RR packet,
additional RR packets may be stacked after the initial SR or RR
packet as needed to contain the reception reports for all sources
heard during the interval since the last report.
The next sections define the formats of the two reports, how they may
be extended in a profile-specific manner if an application requires
additional feedback information, and how the reports may be used.
Details of reception reporting by translators and mixers is given in
Section 7.
6.3.1 SR: Sender report RTCP packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| NTP timestamp, most significant word | sender
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost | cumulative number of packets lost | 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender report packet consists of three sections, possibly
followed by a fourth profile-specific extension section if defined.
The first section, the header, is 8 octets long. The fields have the
following meaning:
version (V): 2 bits
Identifies the version of RTP, which is the same in RTCP packets
as in RTP data packets. The version defined by this
specification is two (2).
padding (P): 1 bit
If the padding bit is set, this RTCP packet contains some
additional padding octets at the end which are not part of the
control information. The last octet of the padding is a count of
how many padding octets should be ignored. Padding may be needed
by some encryption algorithms with fixed block sizes. In a
compound RTCP packet, padding should only be required on the
last individual packet because the compound packet is encrypted
as a whole.
reception report count (RC): 5 bits
The number of reception report blocks contained in this packet.
A value of zero is valid.
packet type (PT): 8 bits
Contains the constant 200 to identify this as an RTCP SR packet.
length: 16 bits
The length of this RTCP packet in 32-bit words minus one,
including the header and any padding. (The offset of one makes
zero a valid length and avoids a possible infinite loop in
scanning a compound RTCP packet, while counting 32-bit words
avoids a validity check for a multiple of 4.)
SSRC: 32 bits
The synchronization source identifier for the originator of this
SR packet.
The second section, the sender information, is 20 octets long and is
present in every sender report packet. It summarizes the data
transmissions from this sender. The fields have the following
meaning:
NTP timestamp: 64 bits
Indicates the wallclock time when this report was sent so that
it may be used in combination with timestamps returned in
reception reports from other receivers to measure round-trip
propagation to those receivers. Receivers should expect that the
measurement accuracy of the timestamp may be limited to far less
than the resolution of the NTP timestamp. The measurement
uncertainty of the timestamp is not indicated as it may not be
known. A sender that can keep track of elapsed time but has no
notion of wallclock time may use the elapsed time since joining
the session instead. This is assumed to be less than 68 years,
so the high bit will be zero. It is permissible to use the
sampling clock to estimate elapsed wallclock time. A sender that
has no notion of wallclock or elapsed time may set the NTP
timestamp to zero.
RTP timestamp: 32 bits
Corresponds to the same time as the NTP timestamp (above), but
in the same units and with the same random offset as the RTP
timestamps in data packets. This correspondence may be used for
intra- and inter-media synchronization for sources whose NTP
timestamps are synchronized, and may be used by media-
independent receivers to estimate the nominal RTP clock
frequency. Note that in most cases this timestamp will not be
equal to the RTP timestamp in any adjacent data packet. Rather,
it is calculated from the corresponding NTP timestamp using the
relationship between the RTP timestamp counter and real time as
maintained by periodically checking the wallclock time at a
sampling instant.
sender's packet count: 32 bits
The total number of RTP data packets transmitted by the sender
since starting transmission up until the time this SR packet was
generated. The count is reset if the sender changes its SSRC
identifier.
sender's octet count: 32 bits
The total number of payload octets (i.e., not including header
or padding) transmitted in RTP data packets by the sender since
starting transmission up until the time this SR packet was
generated. The count is reset if the sender changes its SSRC
identifier. This field can be used to estimate the average
payload data rate.
The third section contains zero or more reception report blocks
depending on the number of other sources heard by this sender since
the last report. Each reception report block conveys statistics on
the reception of RTP packets from a single synchronization source.
Receivers do not carry over statistics when a source changes its SSRC
identifier due to a collision. These statistics are:
SSRC_n (source identifier): 32 bits
The SSRC identifier of the source to which the information in
this reception report block pertains.
fraction lost: 8 bits
The fraction of RTP data packets from source SSRC_n lost since
the previous SR or RR packet was sent, expressed as a fixed
point number with the binary point at the left edge of the
field. (That is equivalent to taking the integer part after
multiplying the loss fraction by 256.) This fraction is defined
to be the number of packets lost divided by the number of
packets expected, as defined in the next paragraph. An
implementation is shown in Appendix A.3. If the loss is negative
due to duplicates, the fraction lost is set to zero. Note that a
receiver cannot tell whether any packets were lost after the
last one received, and that there will be no reception report
block issued for a source if all packets from that source sent
during the last reporting interval have been lost.
cumulative number of packets lost: 24 bits
The total number of RTP data packets from source SSRC_n that
have been lost since the beginning of reception. This number is
defined to be the number of packets expected less the number of
packets actually received, where the number of packets received
includes any which are late or duplicates. Thus packets that
arrive late are not counted as lost, and the loss may be
negative if there are duplicates. The number of packets
expected is defined to be the extended last sequence number
received, as defined next, less the initial sequence number
received. This may be calculated as shown in Appendix A.3.
extended highest sequence number received: 32 bits
The low 16 bits contain the highest sequence number received in
an RTP data packet from source SSRC_n, and the most significant
16 bits extend that sequence number with the corresponding count
of sequence number cycles, which may be maintained according to
the algorithm in Appendix A.1. Note that different receivers
within the same session will generate different extensions to
the sequence number if their start times differ significantly.
interarrival jitter: 32 bits
An estimate of the statistical variance of the RTP data packet
interarrival time, measured in timestamp units and expressed as
an unsigned integer. The interarrival jitter J is defined to be
the mean deviation (smoothed absolute value) of the difference D
in packet spacing at the receiver compared to the sender for a
pair of packets. As shown in the equation below, this is
equivalent to the difference in the "relative transit time" for
the two packets; the relative transit time is the difference
between a packet's RTP timestamp and the receiver's clock at the
time of arrival, measured in the same units.
If Si is the RTP timestamp from packet i, and Ri is the time of
arrival in RTP timestamp units for packet i, then for two packets i
and j, D may be expressed as
D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)
The interarrival jitter is calculated continuously as each data
packet i is received from source SSRC_n, using this difference D for
that packet and the previous packet i-1 in order of arrival (not
necessarily in sequence), according to the formula
J=J+(|D(i-1,i)|-J)/16
Whenever a reception report is issued, the current value of J is
sampled.
The jitter calculation is prescribed here to allow profile-
independent monitors to make valid interpretations of reports coming
from different implementations. This algorithm is the optimal first-
order estimator and the gain parameter 1/16 gives a good noise
reduction ratio while maintaining a reasonable rate of convergence
[11]. A sample implementation is shown in Appendix A.8.
last SR timestamp (LSR): 32 bits
The middle 32 bits out of 64 in the NTP timestamp (as explained
in Section 4) received as part of the most recent RTCP sender
report (SR) packet from source SSRC_n. If no SR has been
received yet, the field is set to zero.
delay since last SR (DLSR): 32 bits
The delay, expressed in units of 1/65536 seconds, between
receiving the last SR packet from source SSRC_n and sending this
reception report block. If no SR packet has been received yet
from SSRC_n, the DLSR field is set to zero.
Let SSRC_r denote the receiver issuing this receiver report. Source
SSRC_n can compute the round propagation delay to SSRC_r by recording
the time A when this reception report block is received. It
calculates the total round-trip time A-LSR using the last SR
timestamp (LSR) field, and then subtracting this field to leave the
round-trip propagation delay as (A- LSR - DLSR). This is illustrated
in Fig. 2.
This may be used as an approximate measure of distance to cluster
receivers, although some links have very asymmetric delays.
6.3.2 RR: Receiver report RTCP packet
[10 Nov 1995 11:33:25.125] [10 Nov 1995 11:33:36.5]
n SR(n) A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005.4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992016.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
A 0xb710:8000 (46864.500 s)
DLSR -0x0005:4000 ( 5.250 s)
LSR -0xb705:2000 (46853.125 s)
-------------------------------
delay 0x 6:2000 ( 6.125 s)
Figure 2: Example for round-trip time computation
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=RR=201 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost | cumulative number of packets lost | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the receiver report (RR) packet is the same as that of
the SR packet except that the packet type field contains the constant
201 and the five words of sender information are omitted (these are
the NTP and RTP timestamps and sender's packet and octet counts). The
remaining fields have the same meaning as for the SR packet.
An empty RR packet (RC = 0) is put at the head of a compound RTCP
packet when there is no data transmission or reception to report.
6.3.3 Extending the sender and receiver reports
A profile should define profile- or application-specific extensions
to the sender report and receiver if there is additional information
that should be reported regularly about the sender or receivers. This
method should be used in preference to defining another RTCP packet
type because it requires less overhead:
o fewer octets in the packet (no RTCP header or SSRC field);
o simpler and faster parsing because applications running under
that profile would be programmed to always expect the extension
fields in the directly accessible location after the reception
reports.
If additional sender information is required, it should be included
first in the extension for sender reports, but would not be present
in receiver reports. If information about receivers is to be
included, that data may be structured as an array of blocks parallel
to the existing array of reception report blocks; that is, the number
of blocks would be indicated by the RC field.
6.3.4 Analyzing sender and receiver reports
It is expected that reception quality feedback will be useful not
only for the sender but also for other receivers and third-party
monitors. The sender may modify its transmissions based on the
feedback; receivers can determine whether problems are local,
regional or global; network managers may use profile-independent
monitors that receive only the RTCP packets and not the corresponding
RTP data packets to evaluate the performance of their networks for
multicast distribution.
Cumulative counts are used in both the sender information and
receiver report blocks so that differences may be calculated between
any two reports to make measurements over both short and long time
periods, and to provide resilience against the loss of a report. The
difference between the last two reports received can be used to
estimate the recent quality of the distribution. The NTP timestamp is
included so that rates may be calculated from these differences over
the interval between two reports. Since that timestamp is independent
of the clock rate for the data encoding, it is possible to implement
encoding- and profile-independent quality monitors.
An example calculation is the packet loss rate over the interval
between two reception reports. The difference in the cumulative
number of packets lost gives the number lost during that interval.
The difference in the extended last sequence numbers received gives
the number of packets expected during the interval. The ratio of
these two is the packet loss fraction over the interval. This ratio
should equal the fraction lost field if the two reports are
consecutive, but otherwise not. The loss rate per second can be
obtained by dividing the loss fraction by the difference in NTP
timestamps, expressed in seconds. The number of packets received is
the number of packets expected minus the number lost. The number of
packets expected may also be used to judge the statistical validity
of any loss estimates. For example, 1 out of 5 packets lost has a
lower significance than 200 out of 1000.
From the sender information, a third-party monitor can calculate the
average payload data rate and the average packet rate over an
interval without receiving the data. Taking the ratio of the two
gives the average payload size. If it can be assumed that packet loss
is independent of packet size, then the number of packets received by
a particular receiver times the average payload size (or the
corresponding packet size) gives the apparent throughput available to
that receiver.
In addition to the cumulative counts which allow long-term packet
loss measurements using differences between reports, the fraction
lost field provides a short-term measurement from a single report.
This becomes more important as the size of a session scales up enough
that reception state information might not be kept for all receivers
or the interval between reports becomes long enough that only one
report might have been received from a particular receiver.
The interarrival jitter field provides a second short-term measure of
network congestion. Packet loss tracks persistent congestion while
the jitter measure tracks transient congestion. The jitter measure
may indicate congestion before it leads to packet loss. Since the
interarrival jitter field is only a snapshot of the jitter at the
time of a report, it may be necessary to analyze a number of reports
from one receiver over time or from multiple receivers, e.g., within
a single network.
6.4 SDES: Source description RTCP packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=SDES=202 | length | header
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC/CSRC_1 | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC/CSRC_2 | chunk
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SDES packet is a three-level structure composed of a header and
zero or more chunks, each of of which is composed of items describing
the source identified in that chunk. The items are described
individually in subsequent sections.
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).
packet type (PT): 8 bits
Contains the constant 202 to identify this as an RTCP SDES
packet.
source count (SC): 5 bits
The number of SSRC/CSRC chunks contained in this SDES packet. A
value of zero is valid but useless.
Each chunk consists of an SSRC/CSRC identifier followed by a list of
zero or more items, which carry information about the SSRC/CSRC. Each
chunk starts on a 32-bit boundary. Each item consists of an 8-bit
type field, an 8-bit octet count describing the length of the text
(thus, not including this two-octet header), and the text itself.
Note that the text can be no longer than 255 octets, but this is
consistent with the need to limit RTCP bandwidth consumption.
The text is encoded according to the UTF-2 encoding specified in
Annex F of ISO standard 10646 [12,13]. This encoding is also known as
UTF-8 or UTF-FSS. It is described in "File System Safe UCS
Transformation Format (FSS_UTF)", X/Open Preliminary Specification,
Document Number P316 and Unicode Technical Report #4. US-ASCII is a
subset of this encoding and requires no additional encoding. The
presence of multi-octet encodings is indicated by setting the most
significant bit of a character to a value of one.
Items are contiguous, i.e., items are not individually padded to a
32-bit boundary. Text is not null terminated because some multi-octet
encodings include null octets. The list of items in each chunk is
terminated by one or more null octets, the first of which is
interpreted as an item type of zero to denote the end of the list,
and the remainder as needed to pad until the next 32-bit boundary. A
chunk with zero items (four null octets) is valid but useless.
End systems send one SDES packet containing their own source
identifier (the same as the SSRC in the fixed RTP header). A mixer
sends one SDES packet containing a chunk for each contributing source
from which it is receiving SDES information, or multiple complete
SDES packets in the format above if there are more than 31 such
sources (see Section 7).
The SDES items currently defined are described in the next sections.
Only the CNAME item is mandatory. Some items shown here may be useful
only for particular profiles, but the item types are all assigned
from one common space to promote shared use and to simplify profile-
independent applications. Additional items may be defined in a
profile by registering the type numbers with IANA.
6.4.1 CNAME: Canonical end-point identifier SDES item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CNAME identifier has the following properties:
o Because the randomly allocated SSRC identifier may change if a
conflict is discovered or if a program is restarted, the CNAME
item is required to provide the binding from the SSRC
identifier to an identifier for the source that remains
constant.
o Like the SSRC identifier, the CNAME identifier should also be
unique among all participants within one RTP session.
o To provide a binding across multiple media tools used by one
participant in a set of related RTP sessions, the CNAME should
be fixed for that participant.
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 RFC1034 [14], RFC1035
[15] and Section 2.1 of RFC1123 [16]; or the standard ASCII
representation of the host's numeric address on the interface used
for the RTP communication. For example, the standard ASCII
representation of an IP Version 4 address is "dotted decimal", also
known as dotted quad. Other address types are expected to have ASCII
representations that are mutually unique. The fully qualified domain
name is more convenient for a human observer and may avoid the need
to send a NAME item in addition, but it may be difficult or
impossible to obtain reliably in some operating environments.
Applications that may be run in such environments should use the
ASCII representation of the address instead.
Examples are "doe@sleepy.megacorp.com" or "doe@192.0.2.89" for a
multi-user system. On a system with no user name, examples would be
"sleepy.megacorp.com" or "192.0.2.89".
The user name should be in a form that a program such as "finger" or
"talk" could use, i.e., it typically is the login name rather than
the personal name. The host name is not necessarily identical to the
one in the participant's electronic mail address.
This syntax will not provide unique identifiers for each source if an
application permits a user to generate multiple sources from one
host. Such an application would have to rely on the SSRC to further
identify the source, or the profile for that application would have
to specify additional syntax for the CNAME identifier.
If each application creates its CNAME independently, the resulting
CNAMEs may not be identical as would be required to provide a binding
across multiple media tools belonging to one participant in a set of
related RTP sessions. If cross-media binding is required, it may be
necessary for the CNAME of each tool to be externally configured with
the same value by a coordination tool.
Application writers should be aware that private network address
assignments such as the Net-10 assignment proposed in RFC1597 [17]
may create network addresses that are not globally unique. This would
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 RFC1627 [18].) To handle this case, applications may
provide a means to configure a unique CNAME, but the burden is on the
translator to translate CNAMEs from private addresses to public
addresses if necessary to keep private addresses from being exposed.
6.4.2 NAME: User name SDES item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the real name used to describe the source, e.g., "John Doe,
Bit Recycler, Megacorp". It may be in any form desired by the user.
For applications such as conferencing, this form of name may be the
most desirable for display in participant lists, and therefore might
be sent most frequently of those items other than CNAME. Profiles may
establish such priorities. The NAME value is expected to remain
constant at least for the duration of a session. It should not be
relied upon to be unique among all participants in the session.
6.4.3 EMAIL: Electronic mail address SDES item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMAIL=3 | length | email address of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The email address is formatted according to RFC822 [19], for
example, "John.Doe@megacorp.com". The EMAIL value is expected to
remain constant for the duration of a session.
6.4.4 PHONE: Phone number SDES item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHONE=4 | length | phone number of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The phone number should be formatted with the plus sign replacing the
international access code. For example, "+1 908 555 1212" for a
number in the United States.
6.4.5 LOC: Geographic user location SDES item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC=5 | length | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Depending on the application, different degrees of detail are
appropriate for this item. For conference applications, a string like
"Murray Hill, New Jersey" may be sufficient, while, for an active
badge system, strings like "Room 2A244, AT&T BL MH" might be
appropriate. The degree of detail is left to the implementation
and/or user, but format and content may be prescribed by a profile.
The LOC value is expected to remain constant for the duration of a
session, except for mobile hosts.
6.4.6 TOOL: Application or tool name SDES item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOOL=6 | length | name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A string giving the name and possibly version of the application
generating the stream, e.g., "videotool 1.2". This information may be
useful for debugging purposes and is similar to the Mailer or Mail-
System-Version SMTP headers. The TOOL value is expected to remain
constant for the duration of the session.
6.4.7 NOTE: Notice/status SDES item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NOTE=7 | length | note about the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following semantics are suggested for this item, but these or
other semantics may be explicitly defined by a profile. The NOTE item
is intended for transient messages describing the current state of
the source, e.g., "on the phone, can't talk". Or, during a seminar,
this item might be used to convey the title of the talk. It should be
used only to carry exceptional information and should not be included
routinely by all participants because this would slow down the rate
at which reception reports and CNAME are sent, thus impairing the
performance of the protocol. In particular, it should not be included
as an item in a user's configuration file nor automatically generated
as in a quote-of-the-day.
Since the NOTE item may be important to display while it is active,
the rate at which other non-CNAME items such as NAME are transmitted
might be reduced so that the NOTE item can take that part of the RTCP
bandwidth. When the transient message becomes inactive, the NOTE item
should continue to be transmitted a few times at the same repetition
rate but with a string of length zero to signal the receivers.
However, receivers should also consider the NOTE item inactive if it
is not received for a small multiple of the repetition rate, or
perhaps 20-30 RTCP intervals.
6.4.8 PRIV: Private extensions SDES item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIV=8 | length | prefix length | prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This item is used to define experimental or application-specific SDES
extensions. The item contains a prefix consisting of a length-string
pair, followed by the value string filling the remainder of the item
and carrying the desired information. The prefix length field is 8
bits long. The prefix string is a name chosen by the person defining
the PRIV item to be unique with respect to other PRIV items this
application might receive. The application creator might choose to
use the application name plus an additional subtype identification if
needed. Alternatively, it is recommended that others choose a name
based on the entity they represent, then coordinate the use of the
name within that entity.
Note that the prefix consumes some space within the item's total
length of 255 octets, so the prefix should be kept as short as
possible. This facility and the constrained RTCP bandwidth should not
be overloaded; it is not intended to satisfy all the control
communication requirements of all applications.
SDES PRIV prefixes will not be registered by IANA. If some form of
the PRIV item proves to be of general utility, it should instead be
assigned a regular SDES item type registered with IANA so that no
prefix is required. This simplifies use and increases transmission
efficiency.
6.5 BYE: Goodbye RTCP packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| length | reason for leaving ... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BYE packet indicates that one or more sources are no longer
active.
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).
packet type (PT): 8 bits
Contains the constant 203 to identify this as an RTCP BYE
packet.
source count (SC): 5 bits
The number of SSRC/CSRC identifiers included in this BYE packet.
A count value of zero is valid, but useless.
If a BYE packet is received by a mixer, the mixer forwards the BYE
packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts
down, it should send a BYE packet listing all contributing sources it
handles, as well as its own SSRC identifier. Optionally, the BYE
packet may include an 8-bit octet count followed by that many octets
of text indicating the reason for leaving, e.g., "camera malfunction"
or "RTP loop detected". The string has the same encoding as that
described for SDES. If the string fills the packet to the next 32-bit
boundary, the string is not null terminated. If not, the BYE packet
is padded with null octets.
6.6 APP: Application-defined RTCP packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The APP packet is intended for experimental use as new applications
and new features are developed, without requiring packet type value
registration. APP packets with unrecognized names should be ignored.
After testing and if wider use is justified, it is recommended that
each APP packet be redefined without the subtype and name fields and
registered with the Internet Assigned Numbers Authority using an RTCP
packet type.
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).
subtype: 5 bits
May be used as a subtype to allow a set of APP packets to be
defined under one unique name, or for any application-dependent
data.
packet type (PT): 8 bits
Contains the constant 204 to identify this as an RTCP APP
packet.
name: 4 octets
A name chosen by the person defining the set of APP packets 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 the allocation of subtype
values to others who want to define new packet types for the
application. Alternatively, it is recommended that others
choose a name based on the entity they represent, then
coordinate the use of the name within that entity. The name is
interpreted as a sequence of four ASCII characters, with
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.
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 RTP level. Although this support adds some complexity to the
protocol, the need for 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
transport protocol (e.g., IP/UDP), multicast address or pair of
unicast addresses, and transport level destination port. (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 for 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 be observed:
o Each of the clouds connected by translators and mixers
participating in one RTP session either must be distinct from
all the others in at least one of these parameters (protocol,
address, port), or must be isolated at the network level from
the others.
o A derivative of the first rule is that there must not be
multiple translators or mixers connected in parallel unless by
some arrangement they partition the set 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.
There may be many varieties of translators and mixers designed for
different purposes and applications. Some examples are to 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
that a translator passes through the data streams from different
sources separately, whereas a mixer combines them to form one new
stream:
Translator: Forwards RTP packets with their SSRC identifier intact;
this makes it possible 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 of the data and
thus the 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 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 combined stream. Since the timing
among multiple input sources will not generally be synchronized,
the mixer will make timing adjustments among the streams and
generate its own timing for the combined stream, so it is the
synchronization source. Thus, all data packets forwarded by a
mixer will be marked with the mixer's own SSRC identifier. In
order to preserve the identity of the original sources
contributing to the mixed packet, the mixer should insert their
SSRC identifiers into the CSRC identifier list following the
fixed RTP header 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, 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 not be detected.
The advantage of a mixer over 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 the input side. This may be
important for low-bandwidth links. The disadvantage is that receivers
on the output side don't have any control over which sources are
passed through or muted, unless some mechanism is implemented for
remote control of the mixer. The regeneration of synchronization
information by 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 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 48 and two CSRC identifiers, 1 and 17,
copied from the SSRC identifiers of packets from E1 and E2.