Connected: An Internet Encyclopedia
6.3.1 SR: Sender report RTCP packet
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1889
Up:
6. RTP Control Protocol -- RTCP
Up:
6.3 Sender and Receiver Reports
Prev: 6.3 Sender and Receiver Reports
Next: 6.3.2 RR: Receiver report RTCP packet
6.3.1 SR: Sender report RTCP packet
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.
Next: 6.3.2 RR: Receiver report RTCP packet
Connected: An Internet Encyclopedia
6.3.1 SR: Sender report RTCP packet