The following sections describe some aspects of the use of RTP. The
examples were chosen to illustrate the basic operation of
applications using RTP, not to limit what RTP may be used for. In
these examples, RTP is carried on top of IP and UDP, and follows the
conventions established by the profile for audio and video specified
in the companion RFC 3551.
2.1 Simple Multicast Audio Conference
A working group of the IETF meets to discuss the latest protocol
document, using the IP multicast services of the Internet for voice
communications. Through some allocation mechanism the working group
chair obtains a multicast group address and pair of ports. One port
is used for audio data, and the other is used for control (RTCP)
packets. This address and port information is distributed to the
intended participants. If privacy is desired, the data and control
packets may be encrypted as specified in Section 9.1, in which case
an encryption key must also be generated and distributed. The exact
details of these allocation and distribution mechanisms are beyond
the scope of RTP.
The audio conferencing application used by each conference
participant sends audio data in small chunks of, say, 20 ms duration.
Each chunk of audio data is preceded by an RTP header; RTP header and
data are in turn contained in a UDP packet. The RTP header indicates
what type of audio encoding (such as PCM, ADPCM or LPC) is contained
in each packet so that senders can change the encoding during a
conference, for example, to accommodate a new participant that is
connected through a low-bandwidth link or react to indications of
network congestion.
The Internet, like other packet networks, occasionally loses and
reorders packets and delays them by variable amounts of time. To
cope with these impairments, the RTP header contains timing
information and a sequence number that allow the receivers to
reconstruct the timing produced by the source, so that in this
example, chunks of audio are contiguously played out the speaker
every 20 ms. This timing reconstruction is performed separately for
each source of RTP packets in the conference. The sequence number
can also be used by the receiver to estimate how many packets are
being lost.
Since members of the working group join and leave during the
conference, it is useful to know who is participating at any moment
and how well they are receiving the audio data. For that purpose,
each instance of the audio application in the conference periodically
multicasts a reception report plus the name of its user on the RTCP
(control) port. The reception report indicates how well the current
speaker is being received and may be used to control adaptive
encodings. In addition to the user name, other identifying
information may also be included subject to control bandwidth limits.
A site sends the RTCP BYE packet (Section 6.6) when it leaves the
conference.
2.2 Audio and Video Conference
If both audio and video media are used in a conference, they are
transmitted as separate RTP sessions. That is, separate RTP 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.
One motivation for this separation is to allow some participants in
the conference to receive only one medium if they choose. Further
explanation is given in Section 5.2. Despite the separation,
synchronized playback of a source's audio and video can be achieved
using timing information carried in the RTCP packets for both
sessions.
2.3 Mixers and Translators
So far, we have assumed that all sites want to receive media data in
the same format. However, this may not always be appropriate.
Consider the case where participants in one area are connected
through a low-speed link to the majority of the conference
participants who enjoy high-speed network access. Instead of forcing
everyone to use a lower-bandwidth, reduced-quality audio encoding, an
RTP-level relay called a mixer may be placed near the low-bandwidth
area. This mixer resynchronizes incoming audio packets to
reconstruct the constant 20 ms spacing generated by the sender, mixes
these reconstructed audio streams into a single stream, translates
the audio encoding to a lower-bandwidth one and forwards the lower-
bandwidth packet stream across the low-speed link. These packets
might be unicast to a single recipient or multicast on a different
address to multiple recipients. The RTP header includes a means for
mixers to identify the sources that contributed to a mixed packet so
that correct talker indication can be provided at the receivers.
Some of the intended participants in the audio conference may be
connected with high bandwidth links but might not be directly
reachable via IP multicast. For example, they might be behind an
application-level firewall that will not let any IP packets pass.
For these sites, mixing may not be necessary, in which case another
type of RTP-level relay called a translator may be used. Two
translators are installed, one on either side of the firewall, with
the outside one funneling all multicast packets received through a
secure connection to the translator inside the firewall. The
translator inside the firewall sends them again as multicast packets
to a multicast group restricted to the site's internal network.
Mixers and translators may be designed for a variety of purposes. An
example is a video mixer that scales the images of individual people
in separate video streams and composites them into one video stream
to simulate a group scene. Other examples of translation include the
connection of a group of hosts speaking only IP/UDP to a group of
hosts that understand only ST-II, or the packet-by-packet encoding
translation of video streams from individual sources without
resynchronization or mixing. Details of the operation of mixers and
translators are given in Section 7.
2.4 Layered Encodings
Multimedia applications should be able to adjust the transmission
rate to match the capacity of the receiver or to adapt to network
congestion. Many implementations place the responsibility of rate-
adaptivity at the source. This does not work well with multicast
transmission because of the conflicting bandwidth requirements 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 the overall live multimedia
"broadcast".
Instead, responsibility for rate-adaptation can be placed at the
receivers by combining a layered encoding with a layered transmission
system. In the context of RTP over IP multicast, the source can
stripe the progressive layers of a hierarchically represented signal
across multiple RTP sessions each carried on its own multicast group.
Receivers can then adapt to network heterogeneity and control their
reception bandwidth by joining only the appropriate subset of the
multicast groups.
Details of the use of RTP with layered encodings are given in
Sections 6.3.9, 8.3 and 11.