RTP: A Transport Protocol for
Real-Time Applications
• 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
RTCP
• RTP 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 Use Scenarios
• Simple Multicast Audio Conference
– 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.
– TP header contains timing information and a sequence
number that allow the receivers to reconstruct the
timing produced by the source.
– The sequence number can also be used by the receiver
to estimate how many packets are being lost.
– the audio application in the conference periodically
multicasts a reception report plus the name of its user
on the RTCP port. The reception report indicates how
well the current speaker is being received.
– A site sends the RTCP BYE packet when it leaves the
conference.
• Audio and Video Conference
– Audio and video media are are transmitted as separate
RTP session and RTCP packets are transmitted for
each medium using two different UDP port pairs and/or
multicast addresses.
– There is no direct coupling at the RTP level between the
audio and video sessions, except that a user
participating in both sessions should use the same
distinguished (canonical) name in the RTCP packets
for both so that the sessions can be associated.
– Despite the separation, synchronized playback of a
source's audio and video can be achieved using timing
information carried in the RTP packets for both
sessions.
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.
• 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
Translator
• Forwards RTP packets with their SSRC
identifier intact
• May change the encoding of the data and
thus the RTP data payload type
RTP Header
Payload type
Timestamp
SSRC identifier
Sequence number
RTCP
• Is based on the periodic transmission of
control packets to all participants in the
session and perform the following
functions:
– provide feedback on the quality of the data
distribution and allows one who is observing
problems to evaluate whether those problems
are local or global.
– RTCP carries an identifier for an RTP source
called the canonical name or CNAME.
Receivers use CNAME to associate multiple
data streams from a given participant in a set of
related RTP sessions, for example to
synchronize audio and video.
RTCP Packet Format
• SR: Sender report, for transmission and
reception statistics from participants that are
active senders.
• RR: Receiver report, for reception statistics
from participants that are not active senders.
• SDES: Source description items, including
CNAME.
• BYE: Indicates end of participation.
• APP: Application specific functions.
RTCP Transmission Interval
• RTP is designed to allow an application to scale
automatically over session sizes ranging from a few
participants to thousands.
• In an audio conference the data traffic is inherently selflimiting 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.
• To maintain scalability, the average interval between
packets from a session participant should scale with the
group size.
• 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 each participant can independently calculate its
share.
• It is suggested that the fraction of the session bandwidth
allocated to RTCP be fixed at 5%
Receiver Report RTCP Packet
RC
Type
Length
SSRC of first source
Fraction lost
Cumulative number of packet lost
Interarrival jitter
Last SR
Delay since last SR
Report block 2
Report block 1
SSRC of packet sender
SRC Identifier Allocation
• The SSRC identifier carried in the 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.
• 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 is
using the same SSRC identifier as its own, it must send
an RTCP BYE packet for the old identifier and choose
another random one.
• If a receiver discovers that two other sources are
colliding, it may keep the packets from one and discard
the packets from the other.