1

RTP protocol
Written by Ahmed Hesham Mostafa,Sec 1,Level 4,CS

Faculty of computer science and information, Helwan University

Introduction
The Real-time Transport Protocol (RTP) defines a standardized packet format for
delivering audio and video over IP networks. RTP is used extensively in
communication and systems that involve streaming media, such as telephony,
video teleconference applications and web-based push to talk features. For these
it carries media streams controlled by H.323, MGCP, Megaco, SCCP, or Session
Initiation Protocol (SIP) signaling protocols, making it one of the technical
foundations of Voice over IP.
RTP is usually used in conjunction with the RTP Control Protocol (RTCP). While
RTP carries the media streams (e.g., audio and video), RTCP is used to monitor
transmission statistics and quality of service (QoS) and aids synchronization of
multiple streams. When both protocols are used in conjunction, RTP is originated
and received on even port numbers and the associated RTCP communication uses
the next higher odd port number.

More generally, RTP makes it possible to:

 Identify the type of information carried.
 Add temporary markers and sequence number to the information carried.
 monitor the packets' arrival at the destination
RTP characteristics
1- Provides end-to-end transport functions for real-time applications
2- Supports different payload types
3- RTP can transport data continuously rather than in bursts, and it can handle
data delivery in multicast environments.
4- RTP takes care of data that TCP cannot handle. Such data can include voice,
video
5- RTP/RTCP are usually implemented within applications --- not as clean cut
as TCP
6- RTP do not Perform signaling (negotiate the media format) other protocol
used to perform signaling such as SIP or H323.
1
 2

RTP in the OSI Layer-Model

RTP was designed to run independently of the underlying transport and network
layers of the OSI model
Application
RTP/RTCP
UDP
IP
Link layer
Physical layer

Figure 1

-How data transfer from client and server in OSI model using RTP Protocol

Figure1 –transfer multimedia (Voice /video) between client and server via RTP

2
 3

RTP Packet
RTP packet generation

1-encoding (at sender) / decoding (at receiver) data.

2-segmentation (at sender) / reassembling (at receiver) of the data
3-add RTP header
4-encapsualte RTP Packets with UDP header
5-encapsualte RTP Packets with IP header to create packets

Figure RTP Packets generation

3
 4

RTP Packet components

 IP Header: UDP Packets are encapsulated in IP datagram

 UDP Header: RTP packets are encapsulated in UDP datagrams (TCP
cannot be used due to overhead and to the fact that most of real time traffic
is multicast)
-Port number is an even number randomly assigned at the session
initiation time
 RTP Header: Variable size, depending on the application (i.e. when
needed). Designed to be small to decrease the overhead.
 RTP Payload: a payload of voice/video samples

IP header UDP header RTP header RTP payload

Figure3- RTP packet

RTP Header

 Version field V: 2 bits long indicates the protocol version (V=2)

 Padding field P: 1 bit, if P is equal to 1, the packet contains additional bytes
for padding to finish the last packet.
 Extension field X: 1 bit, if X=1 the header is followed by an extension
packet
 CSRC count field CC: 4 bits, contains the number of CSRC which follow
the header
 Marker field M: 1 bit, its interpretation is defined by an application profile

4
 5

 Payload type field PT: 7 bits, this field identifies the payload type (audio,
video, image, text, html, etc.)
 Sequence number field: 16 bits, its initial value is random and it
increments by 1 for each packet sent, it can be used to detect lost packets
 Timestamp field: 32 bits, reflects the moment when the first byte of the
RTP packet has been sampled. Used to enable synchronization and the
calculation of the jitter at the destination.
 SSRC field: 32 bits uniquely identify the source, its value is chosen
randomly by the application. The SSRC identifies the synchronization
source (simply called "the source"). This identifier is chosen randomly with
the intent that it is unique among all the sources of the same session.
 CSRC field: 32 bits, identifies contributing sources.

Figure RTP Header

RTP sessions

 A session consists of a group of participants who are communicating using

RTP

5
 6

 A participant may be active in multiple RTP sessions (e.g. one for audio and
one for video)
 For each participant, the session is identified by a network address, a port
pair for sending data and a port pair for receiving data
 Each port pair comprises two adjacent ports An even-numbered port for RTP
data packets
 The next higher (odd-numbered) port for RTCP control packets
 RTP translator or mixer can be used in a session to adapt the data
transmission to participant’s conditions
RTP sessions types
 Multicast (between n nodes).
 Unicast (peer 2 peer).
 Unicast with Mixer/translator
 multicast to unicast

Figure RTP Sessions

Translator and mixer

 Translator
Manage communications between entities that does not support the same
coding scheme
 Mixer

6
 7

Receive RTP packets from a group of sources and combine them into a
single output, possibly changing the encoding, before forwarding the
result

RTCP Protocol
 Designed to be used with RTP and to control an RTP session and 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.
 RTP and RTCP packets belonging to the same session use the same
multicast address but different port number
 RTCP port number = RTP port number + 1
 RTCP packets are sent periodically to provide Periodic reporting of
reception quality (e.g. number of packets sent, number of packets lost, inter-
arrival jitter) ,Notification on changes in session membership and
Information needed to synchronize media streams

RTCP messages:
RTCP has five types of Messages (Reports):

 RR: receiver report. Receiver reports are generated by participants

that are not active senders. They contain reception quality feedback
about data delivery, including the highest packets number received,
the number of packets lost, inter-arrival jitter, and timestamps to
calculate the round-trip delay between the sender and the receiver.
 SR: sender report. Sender reports are generated by active senders. In
addition to the reception quality feedback as in RR, they contain a
sender information section, providing information on inter-media
synchronization, cumulative packet counters, and number of bytes
sent.
 SDES: source description items. They contain information to
describe the sources.
 BYE: indicates end of participation.

7
 8

 APP: application specific functions. It is now intended for

experimental use as new applications and new features are developed.

Figure RTCP Messages

RTCP Packets
RTCP Header
 Version: Identifies the RTP version which is the same in RTCP packets
as in RTP data packets.
 P – Padding: RTCP packet contains some additional padding octets at
the end which are not part of the control information. In a compound
RTCP packet, padding should only be required on the last individual
packet because the compound packet is encrypted as a whole.
 RC- Reception report count: the number of reception report blocks
contained in this packet. A value of zero is valid.
 Length: The length of this RTCP packet in 32-bit words minus one,
including the header and any padding

2 bit 3bit 8 bit 16 bit

Version P RC Packet type

8
 9

Length

Figure RTCP Header

RTCP SR Header

 SR - Section one. The first section is 8 octets long

 Version (V): 2 bits Identifies the version of RTP, which is the same in
RTCP packets as in RTP data packets. The current version 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. That last octet of the padding is a count of how
many padding octets should be ignored.
9
 10

 Reception count: 5 bits the number of reception report blocks contained

in this packet. A value of zero is also valid.
 Packet type: 8 bits Contains the constant 200 to identify this as an RTCP
SR packet.
 Length: 16 bits the length is the RTCP packet in 32 bit words minus one,
including the header and any padding.
 SSRC: 32 bit the synchronization source identifier for the originator of
this SR packet.
 SR - Section two. The second section, the sender information, is 20 octets
long and is presented in every sender report packet. It summarizes the data
transmissions from this sender.
 NTP timestamp: 64 bits Indicates the wall clock 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. A sender that has no notion of wall clock
or elapsed time may set the NTP timestamp to zero.
 RTP timestamp: 32 bits Corresponds to the same time as the NTP
timestamp, but in the same units and with the same random offset as
the RTP timestamps in the data packets.
 Sender PKT counts: 32 bits the total number of 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.
 Sender octet count: 32 bits the total number of payload octets
transmitted in RTP data packets by the sender since starting
transmission. The count is reset if the sender changes its SSRC
identifier. This field can be used to estimate the average payload data
rate.
 SR - Section three. 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.
 SSRC_n (src ident): 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
10
 11

filed. 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.
 Total packets lost: 24 bits Total number of RTP data packets from the
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.
 Last sequence #: 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. Note that different
receivers within the same session will generate different extensions
to the sequence number if their start times differ significantly.
 Inter arrival jitter: 32 bits an estimate of the statistical variance of
the RTP data packet inter-arrival time measured in timestamp units
and expressed as an unsigned integer. The inter-arrival jitter J is
defined to be the mean deviation 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 (i and j). The relative transit
time is the difference between a packets RTP timestamp Si and the
receiver's clock at the time of arrival, RI measured in the same units.

11
 12

RTCP RR Header

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.

12
 13

RTCP SDES Header

 RTCP SDES Header Description

 Version (V), SSRC, Padding (P), length: see SR packet description
 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.
 SDES item: n bits the source description item has to be unique among
all session participants, one good choice is to use the canonical name
of the source.

RTCP BYE Header

13
 14

 RTCP BYE Header Description

 Version (V), SSRC, Padding (P), length: see SR packet description.
 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.

How RTP/RTCP Protocols work together

An RTP Session is established for each multimedia stream. A session consists of an
IP address with a pair of ports for RTP and RTCP. For example, audio and video
streams will have separate RTP sessions, enabling a receiver to deselect a
particular stream. The ports which form a session are negotiated using other
protocols SIP or H323. According to the specification, an RTP port should be even
and the RTCP port is the next higher odd port number. RTP and RTCP typically use
unprivileged UDP ports (1024 to 65535).

 Each participant uses two ports. One for audio data and the
other for control (RTCP) packets
 Each participant sends audio data in small chunks of say 20 mS
duration
 A RTP header is added which contains the timing field that
ensures that the chunks of data are continuously played for
every 20mS
 Both audio and video are transmitted as two separate RTP
sessions.
 Separate RTP and RTCP packets are transmitted for each
medium using two UDP port pairs and multicast addresses.
 No direct coupling at the RTP level between the audio and
video sessions

14
 15

Figure RTP and RTCP Packet s transamination

15