RTP payload: The data transported by RTP in a packet, for
example audio samples or compressed video data. The payload
format and interpretation are beyond the scope of this document.
RTP packet: A data packet consisting of the fixed RTP header, a
possibly empty list of contributing sources (see below), and the
payload data. Some underlying protocols may require an
encapsulation of the RTP packet to be defined. Typically one
packet of the underlying protocol contains a single RTP packet,
but several RTP packets MAY be contained if permitted by the
encapsulation method (see Section 11).
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 the RTCP packet type. The
formats are defined in Section 6. Typically, multiple RTCP
packets are sent together as a compound RTCP packet in a single
packet of the underlying protocol; this is enabled by the length
field in the fixed header of each RTCP 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." [12] The transport selectors (TSEL) used by the OSI
transport layer are equivalent 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 a network address and port
that identifies a transport-level endpoint, 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 the collection of payload
types which can be carried within a single RTP session. The RTP
Profile assigns RTP media types to RTP payload types.
Multimedia session: A set of concurrent RTP sessions among a
common group of participants. For example, a videoconference
(which is a multimedia session) may contain an audio RTP session
and a video RTP session.
RTP session: An association among a set of participants
communicating with RTP. A participant may be involved in multiple
RTP sessions at the same time. In a multimedia session, each
medium is typically carried in a separate RTP session with its own
RTCP packets unless the the encoding itself multiplexes multiple
media into a single data stream. A participant distinguishes
multiple RTP sessions by reception of different sessions using
different pairs of destination transport addresses, where a pair
of transport addresses comprises one network address plus a pair
of ports for RTP and RTCP. All participants in an RTP session may
share a common destination transport address pair, as in the case
of IP multicast, or the pairs may be different for each
participant, as in the case of individual unicast network
addresses and port pairs. In the unicast case, a participant may
receive from all other participants in the session using the same
pair of ports, or may use a distinct pair of ports for each.
The distinguishing feature of an RTP session is that each
maintains a full, separate space of SSRC identifiers (defined
next). The set of participants included in one RTP session
consists of those that can receive an SSRC identifier transmitted
by any one of the participants either in RTP as the SSRC or a CSRC
(also defined below) or in RTCP. For example, consider a three-
party conference implemented using unicast UDP with each
participant receiving from the other two on separate port pairs.
If each participant sends RTCP feedback about data received from
one other participant only back to that participant, then the
conference is composed of three separate point-to-point RTP
sessions. If each participant provides RTCP feedback about its
reception of one other participant to both of the other
participants, then the conference is composed of one multi-party
RTP session. The latter case simulates the behavior that would
occur with IP multicast communication among the three
participants.
The RTP framework allows the variations defined here, but a
particular control protocol or application design will usually
impose constraints on these variations.
Synchronization source (SSRC): The source of a stream of RTP
packets, identified by a 32-bit numeric SSRC identifier carried in
the RTP header so as not 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 by
synchronization source for playback. Examples of synchronization
sources include the sender of a stream 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 SSRC identifier is a
randomly chosen value meant to be 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
multimedia session; the binding of the SSRC identifiers is
provided through RTCP (see Section 6.5.1). If a participant
generates multiple streams in one RTP session, for example from
separate video cameras, each MUST be identified as a different
SSRC.
Contributing source (CSRC): A source of a stream of RTP packets
that has contributed to the combined stream produced by an RTP
mixer (see below). The mixer inserts a list of the SSRC
identifiers of the sources that contributed to the generation of a
particular packet into the RTP header of that packet. This list
is called the CSRC list. An example application is audio
conferencing where a mixer indicates all the talkers whose speech
was combined to produce the outgoing packet, allowing the receiver
to indicate the current talker, even though all the audio packets
contain the same SSRC identifier (that of the mixer).
End system: An application that generates the content to be sent
in RTP packets and/or consumes the content of received RTP
packets. An end system can act as 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
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.
Thus, all data packets originating from a mixer will be identified
as having the 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
participants in an RTP session, in particular the reception
reports, and estimates the current quality of service for
distribution monitoring, fault diagnosis and long-term statistics.
The monitor function is likely to be built into the application(s)
participating in the session, but may also be a separate
application that does not otherwise participate and does not send
or receive the RTP data packets (since they are on a separate
port). These are called third-party monitors. It is also
acceptable for a third-party monitor to receive the RTP data
packets but not send RTCP packets or otherwise be counted in the
session.
Non-RTP means: Protocols and mechanisms that may be needed in
addition to RTP to provide a usable service. In particular, for
multimedia conferences, a control protocol 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 the payload formats they
represent for formats that do not have a predefined payload type
value. Examples of such protocols include the Session Initiation
Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14] and
applications using SDP (RFC 2327 [15]), such as RTSP (RFC 2326
[16]). For simple
applications, electronic mail or a conference database may also be
used. The specification of such protocols and mechanisms is
outside the scope of this document.